Execution PythonEcosystems

Python Ecosystems For Revit

Revit Python development has several runtime options. Choose based on the workflow you need: modern packages, direct .NET compatibility, visual programming, or team deployment.

Quick Choice

Need	Recommended option
Modern Python packages	RevitDevTool CPython
VSCode breakpoints	RevitDevTool CPython
Data analysis / ML / computational geometry	RevitDevTool CPython
Existing IronPython or pyRevit scripts	RevitDevTool IronPython or pyRevit
Visual graph workflow	Dynamo Python
Team ribbon deployment	pyRevit
Simple no-package Revit API automation	IronPython or compiled .NET

Runtime Comparison

Runtime	Best for	Strengths	Tradeoffs
RevitDevTool CPython	package-heavy development	modern Python, PEP 723 dependencies, VSCode debugging	uses PythonNet for .NET interop
RevitDevTool IronPython	IronPython scripts and existing pyRevit/RevitPythonShell-style code	first-class IronPython mode, first-class pyRevit runtime support when available, IronPython 3.4.2 fallback	no modern CPython package ecosystem
pyRevit IronPython	ribbon automation and team scripts	mature extension model, direct CLR style	older Python ecosystem
pyRevit CPython	experimentation	CPython access inside pyRevit ecosystem	manual/runtime caveats vary by setup
Dynamo CPython	graph + Python workflows	visual programming, bundled packages	less suited for code-first debugging
Compiled .NET	production add-ins	strong typing, host-native API model	slower iteration than scripts

RevitDevTool CPython

Use this for new Python work when packages matter.

Good fit:

• model data extraction;
• dataframe analysis;
• Excel/report generation;
• geometry processing;
• research scripts;
• AI/ML experiments;
• scripts that benefit from VSCode debugging.

Dependency example:

# /// script
# dependencies = [
#     "polars==1.38.1",
#     "numpy==2.4.2",
#     "openpyxl==3.1.5",
# ]
# ///

Current package preparation is Pixi-first, with pip/pyRevit CPython fallback when Pixi cannot be used.

IronPython

Use IronPython when IronPython/.NET behavior or compatibility is more important than modern CPython packages.

Good fit:

• existing pyRevit/RevitPythonShell-style scripts;
• simple Revit API automation;
• workflows that do not need NumPy, pandas, Polars, Shapely, or other CPython packages.

In RevitDevTool, IronPython is not limited to pyRevit as the only execution path. RevitDevTool uses pyRevit runtime support as a first-class path when available, then falls back to IronPython 3.4.2 when pyRevit is not available.

Dynamo Python

Use Dynamo Python when the surrounding workflow is a Dynamo graph.

Good fit:

• visual programming;
• graph-controlled inputs/outputs;
• Dynamo package ecosystem;
• workflows used by designers who prefer node graphs.

pyRevit

Use pyRevit when the main goal is distributing buttons and automations to users.

Good fit:

• team ribbon tools;
• established pyRevit extensions;
• reusable buttons;
• end-user automation workflows.

RevitDevTool can still be useful beside pyRevit for development, debugging, package experiments, and IronPython/CPython compatibility workflows.

Interface And .NET Interop Notes

CPython uses PythonNet to talk to .NET APIs. This gives access to modern Python packages, but .NET interop is not identical to IronPython.

Watch for:

• .NET interface implementation differences;
• overload resolution;
• extension methods;
• out/ref style APIs;
• dynamic object behavior inside the debugger.

For pure Revit API automation with heavy .NET interop and no Python packages, IronPython or compiled .NET may be simpler. For package-heavy work, CPython is usually the better choice.

Related Examples

• Data Analysis
• Dashboard
• Visualization Curves
• Python Debugging
• RevitDevTool And pyRevit