GO — Healthy across all four use cases

• Last commit 5d ago
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 92% of recent commits
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Dear PyGui is a GPU-accelerated immediate-mode GUI framework for Python that wraps Dear ImGui with Python bindings, enabling fast, modern desktop applications with minimal dependencies. It specializes in high-performance data visualization (plotting 1M+ points at 60 fps), node editors, and theme customization while remaining a thin layer between Python and optimized C++/C rendering code. Monorepo structure: dearpygui/ contains Python entry points (init.py, dearpygui.py, demo.py), type stubs (_dearpygui.pyi), and wrappers (_header.py, _deprecated.py, experimental.py); the compiled C++ extension (_dearpygui module) is pre-built and distributed via PyPI. Documentation lives in docs/source/ with Sphinx+ReadTheDocs. CMakeLists.txt orchestrates the C++/C build for distributing platform wheels.

Python developers building scientific/engineering desktop tools, data analysis dashboards, and real-time visualization applications who need responsive, GPU-backed UI without the overhead of Qt/wxPython but with full theme control and modern aesthetics.

Actively maintained with established CI/CD (EmbeddedBuild, static-analysis, Deployment workflows in .github/workflows/), published to PyPI, and comprehensive documentation via ReadTheDocs (.readthedocs.yaml configured). The C++/C codebase is substantial (~1.8M LOC), indicating production maturity, though the single main maintainer (hoffstadt) and MIT license suggest community-driven development rather than corporate backing.

Single primary maintainer (hoffstadt, see .github/CODEOWNERS) creates continuity risk; external dependency on Dear ImGui C library requires monitoring upstream changes. Minimal runtime dependencies are a strength, but C++ FFI layer (Python-to-C++ binding) can make debugging harder. Breaking changes historically occur (see .github/CHANGELOG.md), so semantic versioning adherence should be verified before upgrading in production.

Visible from structure: active documentation maintenance (.readthedocs.yaml, docs/source/documentation/ with recent topics like container-context-manager.rst, filter-set.rst), experimental features tracked in dearpygui/experimental.py, type checking support via _dearpygui.pyi, and multi-platform CI ensuring Windows/Linux/macOS compatibility via workflows.

git clone https://github.com/hoffstadt/DearPyGui.git
cd DearPyGui
pip install -e .
python -c 'import dearpygui.dearpygui as dpg; dpg.show_demo()'

Daily commands:

pip install dearpygui
python -c 'from dearpygui import dearpygui as dpg; dpg.create_context(); dpg.create_viewport(title="Hello"); dpg.setup_dearpygui(); dpg.show_viewport(); dpg.start_dearpygui()'

• dearpygui/__init__.py — Main package entry point that exports the core Dear PyGui API and initializes the binding to the native C++ backend
• dearpygui/dearpygui.py — High-level Python wrapper providing the main API surface for GUI creation, item management, and event handling
• src/dearpygui.cpp — Core C++ implementation containing the ImGui-based rendering engine and Python binding logic
• src/dearpygui.h — Central C++ header defining core data structures, item types, and the application framework
• CMakeLists.txt — Build configuration orchestrating compilation of C++ backend and Python packaging across platforms
• dearpygui/_dearpygui.pyi — Type stubs for the compiled _dearpygui module, enabling IDE autocomplete and type checking
• setup.py — Python package distribution configuration and wheel building for PyPI deployment

• Python API Wrapper (dearpygui/dearpygui.py) _(Pure Python, ctypes FFI to dearpygui module) — Provides Pythonic context managers, convenience functions, and the render loop orchestration
  • Failure mode: If wrapper crashes, user script can catch exceptions; render loop may deadlock if callback blocks indefinitely
• C++ Backend (src/dearpygui.cpp) (C++17, ImGui, platform-specific windowing APIs) — Core item management, state persistence, callback dispatch, and ImGui integration
  • Failure mode: Segfaults in C++ code will crash entire process with no Python exception; memory corruption can cause silent data loss
• Item Hierarchy (src/mvAppItem.*) — Base class and derived types for all UI elements; handles drawing

Add a new UI widget type

1. Define the item class in C++ header (src/dearpygui.h)
2. Implement widget logic and state management in C++ (src/dearpygui.cpp)
3. Register command handlers and callbacks (src/dearpygui_commands.h)
4. Add type stubs for Python type checking (dearpygui/_dearpygui.pyi)
5. Create convenience wrapper in Python API (optional) (dearpygui/dearpygui.py)

Add a new item callback or configuration option

1. Add parameter field to item class definition (src/dearpygui.h)
2. Implement getter/setter in item class and draw logic (src/dearpygui.cpp)
3. Register parameter parser and type information (src/dearpygui_parsers.h)
4. Update type stubs to expose new parameter (dearpygui/_dearpygui.pyi)

Add a new platform or build target

1. Extend CMake configuration with platform-specific rules (CMakeLists.txt)
2. Add platform-specific C++ code if needed (src/dearpygui.cpp)
3. Create or update build script (scripts/BuildPythonForWindows.bat)
4. Configure GitHub Actions workflow for CI/CD (.github/workflows/Deployment.yml)

• ImGui (Dear ImGui) — Immediate mode GUI framework providing fast, responsive rendering with minimal overhead; excellent for real-time applications and data visualization
• Python C API / pybind11 concepts — Direct binding to compiled C++ backend provides orders-of-magnitude performance improvement over pure-Python GUI frameworks while maintaining Pythonic API
• CMake — Cross-platform build system supporting complex dependency management and platform-specific compilation for Windows, macOS, and Linux
• Sphinx + RST documentation — Industry-standard documentation tooling integrated with ReadTheDocs for automatic hosting and versioning

• Immediate mode GUI instead of retained mode

  • Why: Simpler API, fewer bugs from stale state, instant responsiveness to input
  • Consequence: Slightly higher CPU usage per frame; requires redrawing entire UI each frame rather than updating changed elements

• C++ backend with Python wrapper instead of pure Python

  • Why: Achieves 60+ FPS rendering and handles complex layouts efficiently; accessible to Python developers
  • Consequence: Increased build complexity; deployment requires platform-specific wheels; harder to extend with pure Python

• Single viewport model with context manager pattern

  • Why: Simpler mental model and API surface; matches ImGui's single-context design
  • Consequence: No native support for multiple independent windows; workaround needed for multi-window applications

• Generated type stubs instead of inline type hints

  • Why: Necessary for C extension modules; allows IDE autocomplete and static type checking
  • Consequence: Type information must be manually maintained separate from implementation; risk of divergence

• Does not provide platform-native look-and-feel (uses ImGui's consistent styling across platforms)
• Does not support accessibility features like screen readers (ImGui limitation)
• Not a web-based UI framework (desktop/windowed applications only)
• Does not include built-in theme designer (themes defined programmatically)
• No native support for CSS-like styling (uses ImGui's parameter-based theming)

• No pure-Python fallback: _dearpygui is a pre-compiled extension; building from source requires C++ toolchain (MSVC on Windows, GCC/Clang on Linux/macOS, see CMakeLists.txt). - Immediate-mode paradigm: unlike declarative frameworks (Qt/wxPython), every frame reruns callback code; state must be managed explicitly or via context managers to avoid bugs. - Platform wheel dependency: pre-built wheels for specific Python versions/platforms are published via PyPI; mismatched versions will fail import. - Global context requirement: dpg.create_context() must be called before any UI operations; forgetting this is a common gotcha. - Dear ImGui upstream coupling: breaking changes in upstream Dear ImGui may require re-binding in _header.py and recompilation.

• Immediate-mode GUI (ImGUI) — DearPyGui's core paradigm: UI is rebuilt every frame via stateless callback functions rather than retained object trees; enables responsive, real-time UIs but requires different thinking than Qt/wxPython
• GPU-accelerated rendering (OpenGL/DirectX) — Dear ImGui uses GPU for all drawing via OpenGL/DirectX, enabling 1M+ point plot rendering at 60 fps; critical for understanding why DearPyGui outperforms CPU-only frameworks
• Python C extensions (ctypes/FFI bindings) — DearPyGui ships as a compiled _dearpygui module wrapping C++/C code; understanding the FFI layer helps debug crashes, handle missing features, and reason about performance
• Context managers and decorator patterns — DearPyGui uses Python context managers (with dpg.theme():) and decorators (@dpg.callback) for ergonomic immediate-mode UI building; idiomatic to the framework
• Async/await integration with GUI event loops — DearPyGui supports asynchronous function callbacks and integrates with asyncio; critical for long-running tasks without blocking the UI (see dearpygui/dearpygui.py async patterns)
• Theme and style abstraction — DearPyGui provides theme/style system for runtime customization (modern look goal); differs from hard-coded styling in simpler frameworks and requires understanding dpg theme/style dictionaries
• Wheel distribution and platform-specific binaries — DearPyGui pre-builds wheels for Windows/Linux/macOS and multiple Python versions (.github/workflows/Deployment.yml); understanding this avoids 'module not found' errors on unsupported platforms

• ocornut/imgui — The upstream C++ Dear ImGui library that DearPyGui wraps; essential for understanding rendering and immediate-mode architecture
• epezent/implot — Built into DearPyGui via ImPlot bindings; handles 1M+ point plotting and is displayed in the README GIFs
• PySimpleGUI/PySimpleGUI — Alternative Python GUI framework with similar goals (ease-of-use, rapid prototyping) but uses traditional retained-mode API and Tkinter/Qt backends
• kivy/kivy — Cross-platform Python GUI framework with GPU rendering, but targets mobile/touch; DearPyGui focuses on desktop and data visualization
• hoffstadt/DearImGui.NET — Same author's C# bindings for Dear ImGui; shows parallel effort to make Dear ImGui accessible across languages

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive type hints and stub file validation for dearpygui module

The repo has dearpygui/_dearpygui.pyi stub file but lacks validation and tests to ensure it stays synchronized with the actual C++ bindings. A new contributor could add type checking tests using tools like mypy or pyright against the dearpygui package, catch mismatches early, and document the stub file generation process. This improves IDE support and type safety for users.

• [ ] Create tests/type_checking/ directory with mypy configuration
• [ ] Add GitHub Action workflow to validate _dearpygui.pyi against actual bindings using pyright
• [ ] Create documentation in docs/source/documentation/ explaining type stub maintenance
• [ ] Add pre-commit hook configuration to .github/ for type checking
• [ ] Document the process in CONTRIBUTING.md for keeping stubs synchronized

Implement integration tests for the demo.py and experimental.py modules

The repo has dearpygui/demo.py and dearpygui/experimental.py but no visible test suite validating these modules work correctly. A contributor could create integration tests that verify demos run without errors, experimental features initialize properly, and edge cases are handled. This prevents regressions when core features change.

• [ ] Create tests/integration/ directory with test_demo.py and test_experimental.py
• [ ] Add headless/offscreen rendering tests for demo scenarios from dearpygui/demo.py
• [ ] Test experimental.py features with proper setup/teardown to avoid display dependencies
• [ ] Add GitHub Action workflow to run integration tests on multiple Python versions
• [ ] Document testing approach in CONTRIBUTING.md for future contributors

Create missing documentation for deprecation path and type_info module usage

The repo has dearpygui/_deprecated.py and dearpygui/type_info.py but no corresponding documentation in docs/source/documentation/. Users upgrading versions have no guidance on deprecated features, and the type_info module's purpose is undocumented. A contributor could add practical guides with code examples.

• [ ] Create docs/source/documentation/deprecation-guide.rst covering _deprecated.py patterns and migration paths
• [ ] Create docs/source/documentation/type-info-module.rst explaining type_info.py usage with examples
• [ ] Add both files to docs/source/conf.py toctree
• [ ] Include version compatibility notes in each guide referencing CHANGELOG.md
• [ ] Add examples showing common deprecation warnings and how to fix them

• Add missing type hints to dearpygui/dearpygui.py function signatures (check _dearpygui.pyi coverage vs. actual exports); improves IDE support for all users.
• Expand docs/source/documentation/ with a 'File I/O and Callbacks' guide showing callback patterns (dearpygui/demo.py has examples); currently only file-directory-selector.rst and io-handlers-state.rst exist.
• Create a 'Common Patterns' example file (e.g., dearpygui/examples/patterns.py) showing context manager usage, state management, and async tasks; referenced in README but missing from repo structure.

The DearPyGui repository demonstrates a reasonable security posture for a GUI framework project. The primary concerns are outdated dependencies, particularly Sphinx and related documentation tools that are over 3 years old and no longer receiving security updates. The codebase lacks explicit security documentation and dependency pinning strategies. No obvious injection vulnerabilities, hardcoded secrets, or critical misconfigurations were detected in the provided file structure. The project would benefit from updating dependencies to current versions and establishing a clear security reporting policy.

• Medium · Outdated Sphinx Documentation Dependencies — Dependencies/Package file - Sphinx==4.1.2, sphinx-rtd-theme==0.5.2. The dependencies file specifies Sphinx==4.1.2 (released April 2021) and sphinx-rtd-theme==0.5.2 (released May 2021). These versions are significantly outdated and may contain known security vulnerabilities. Sphinx 4.1.2 is over 3 years old and no longer receives security updates. Fix: Update to the latest stable versions of Sphinx (currently 7.x) and sphinx-rtd-theme (currently 2.x). Run 'pip install --upgrade sphinx sphinx-rtd-theme' and test documentation generation thoroughly.
• Medium · Outdated Pillow Dependency Without Version Pinning — Dependencies/Package file - Pillow. Pillow is listed without a specific version constraint, which could lead to unexpected behavior if a vulnerable version is installed. Additionally, older versions of Pillow have had known security vulnerabilities related to image processing. Fix: Pin Pillow to a specific secure version: 'Pillow>=10.0.0' (or the latest stable version). Consider adding an upper bound to prevent major version changes without testing.
• Low · Missing Security Policy Documentation — Repository root / .github directory. No SECURITY.md or security policy file is present in the repository root or .github directory. This makes it unclear how users should report security vulnerabilities responsibly. Fix: Create a SECURITY.md file in the repository root following the GitHub security advisory guidelines. Include responsible disclosure procedures and contact information for reporting security issues.
• Low · Outdated Alabaster Theme Dependency — Dependencies/Package file - alabaster==0.7.12. Alabaster==0.7.12 is pinned to an older version (from 2019). While less critical than Sphinx itself, it should be updated to benefit from any security improvements. Fix: Update alabaster to the latest stable version (currently 0.7.13+). Run 'pip install --upgrade alabaster'.
• Low · No Dependency Lock File Present — Repository root. The repository does not appear to have a requirements.lock, poetry.lock, or pipenv.lock file. This can lead to reproducibility issues and makes it harder to ensure consistent security across deployments. Fix: Generate and commit a lock file using one of: pip-tools (pip-compile), Poetry, or Pipenv. This ensures all transitive dependencies are explicitly pinned and reproducible.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/hoffstadt/DearPyGui shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live hoffstadt/DearPyGui repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hoffstadt/DearPyGui.

What it runs against: a local clone of hoffstadt/DearPyGui — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in hoffstadt/DearPyGui | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of hoffstadt/DearPyGui. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/hoffstadt/DearPyGui.git
#   cd DearPyGui
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of hoffstadt/DearPyGui and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hoffstadt/DearPyGui(\\.git)?\\b" \\
  && ok "origin remote is hoffstadt/DearPyGui" \\
  || miss "origin remote is not hoffstadt/DearPyGui (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "dearpygui/__init__.py" \\
  && ok "dearpygui/__init__.py" \\
  || miss "missing critical file: dearpygui/__init__.py"
test -f "dearpygui/dearpygui.py" \\
  && ok "dearpygui/dearpygui.py" \\
  || miss "missing critical file: dearpygui/dearpygui.py"
test -f "src/dearpygui.cpp" \\
  && ok "src/dearpygui.cpp" \\
  || miss "missing critical file: src/dearpygui.cpp"
test -f "src/dearpygui.h" \\
  && ok "src/dearpygui.h" \\
  || miss "missing critical file: src/dearpygui.h"
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/hoffstadt/DearPyGui"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.