CQ-editor is a viewer that re-runs your script, not a modeller

The editor does not edit, it re-runs

The first feature in the list sets the whole design: automatic code reloading, so you can use your favourite editor.

That phrase is doing the work. CQ-editor is not a modelling application with a property panel. It watches a CadQuery script, and when you save it, it re-executes the script and shows you the resulting geometry in a 3D view.

So the workflow is: write CadQuery in whatever editor you already use, save, and look at the result. There is no tool palette, no constraint solver and no feature tree to learn. The script is the model, and the script is the source of truth.

That is a much better fit for learning CadQuery than a conventional CAD interface, because everything that happens in the model is something you typed. When a fillet fails, you did not click the wrong option in a dialog; you wrote a call the kernel rejected.

The consequence is also a constraint. Anything the script cannot express is not available, and the two export formats listed, STL and STEP, are what you get at the end rather than a full drawing package.

The renderer is OCCT based.

The application supports Linux, Windows and Mac, and the screenshot and the wiki's screenshot page are the documentation for what it looks like.

The debugger and the object stack are what make it a learning tool

Two features go beyond showing a shape, and they are aimed at someone writing CadQuery for the first time.

The graphical debugger for CadQuery scripts lets you step through the script and watch how the model changes. That is a real debugger for a Python script that builds geometry incrementally, and it maps well onto how you think about the problem: you can stop after the workplane is created, after the profile is sketched, after the extrude, and look at what each step produced.

The CadQuery object stack inspector gives visual inspection of the current workplane and selected items, and insight into the evolution of the model.

That second one is more specific than it sounds. CadQuery is built on the idea that operations return new objects, and understanding where you are in a chain of those objects is the main thing beginners get lost about. An inspector that shows the current workplane and the selected items turns an invisible piece of state into something on screen.

Together they address the same problem from two directions. The debugger lets you move through time in the script, and the stack inspector shows you where you are in the data at any point.

The third presentation feature is the navigation cube with rotation arrows. It always shows the current camera orientation, and you can click faces, edges or corners for one-click animated reorientation.

That is a small thing that matters in practice. In a 3D view with an isometric default, a rotation control that tells you where you are looking is the difference between navigating and getting lost.

Two packaging files declare two different entry points

This repository has both a `pyproject.toml` and a `setup.py`, and they do not agree.

In pyproject.toml the scripts section reads:

[project.scripts]
CQ-editor = "cq_editor.cqe_run:main"
cq-editor = "cq_editor.cqe_run:main"

In setup.py the entry points read:

entry_points={
    "gui_scripts": [
        "cq-editor = cq_editor.__main__:main",
        "CQ-editor = cq_editor.__main__:main",
    ]
},

Two differences. The module is `cq_editor.cqe_run` in one and `cq_editor.__main__` in the other, and pyproject declares them under `scripts` while setup.py uses `gui_scripts`, which on Windows means no console window.

Whichever build path you use, you get a `cq-editor` and a `CQ-editor` command on your path, so the command name is not the problem. But if you are debugging a packaging issue, this is where to look, and it is also a good reason to install from a release artefact rather than reasoning about which file is authoritative.

The rest of the metadata is more settled. The version in pyproject.toml is `0.8.dev0`, while the last published release is 0.7.0 from 2026-04-08, so the development branch uses a newer development version.

Python support is declared as `>=3.10,<=3.14`, with a closed upper bound, which is unusual and worth noting: an upper bound means a Python 3.15 user cannot install this even if it would probably work.

The dependencies are short and tell you what the application actually needs: `cadquery`, `PyQt5`, `pyqtgraph`, `qtawesome` pinned to 1.4.0, `logbook`, `requests`, `qtconsole` with an upper bound of 5.7.0, `path` and `packaging`.

Two exact or bounded pins in a nine-package list is a sign of an older Qt stack meeting newer Python versions.

The examples directory is the tutorial

There are eight example scripts at the repository root under `examples/`, and their filenames are the documentation.

They run `01_hello_box.py`, `02_selectors_and_fillets.py`, `03_extruded_profile.py`, `04_holes_and_counterbores.py`, `05_loft.py`, `06_sweep.py`, `07_pillow_block.py` and `08_assembly.py`.

The sequence teaches the language in the order it needs to be learned. A box is the hello world of a solid model. Then selectors and fillets, which is the CadQuery concept that confuses newcomers because you select edges by position and by face rather than clicking them. Then an extruded profile, which is the core parametric operation. Then holes and counterbores, which is a small shape with real manufacturing meaning.

Loft and sweep are the two harder operations. A pillow block is a real mechanical part and a classic test case because it has a bore, a fillet and a mounting face. And an assembly is last because it needs everything before it.

Since the editor reloads on save, the intended way to use these is to open one, run it, then modify it and save. There is no separate tutorial to keep in sync with the code, because the examples are the tutorial.

That also means the examples double as a compatibility check. If your Python or your CadQuery version changes behaviour, running `01_hello_box.py` and seeing a box tells you the stack still works before you start anything complicated.

The rest of the repository supports that: `run.py` at the root, a `runtests_locally.sh` script, `pytest.ini` and a `.coveragerc`, plus `pyinstaller.spec` and a `pyinstaller/` directory for the packaged builds, a `conda/` directory and a `cqgui_env.yml` for a conda environment, and `changes.md` for the changelog.

Editorial conclusion

Adopt CQ-editor if you are learning or iterating on CadQuery and want to see the shape change as you type rather than running a script and waiting. Skip it if you need a full CAD application with assemblies, constraints and drawing output, since this is a viewer and exporter for an existing CadQuery script. Verify first which entry point your install actually provides, because pyproject.toml and setup.py declare differently named console scripts pointing at different modules.

Frequently asked questions

Official sources

1. CadQuery/CQ-editor on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases