When I started learning about FreeCAD, I also learned about its 3D modeling core OpenCascade Technology (OCCT). OCCT is not exclusive to FreeCAD and it forms the core of several other open-source CAD solutions, each implementing a different design intent. In the time I've been keeping my eyes open, I've come across several projects that might be interesting.

First up on this survey is CadQuery, a Python API on top of OCCT. (Hackaday post) Which is very interesting considering FreeCAD already has a Python API. From a brief look, those two APIs have different intentions on how to expose OCCT capability to code-based construction. FreeCAD's Python API primarily enable macros, scripts, and extensions to supplement projects created in FreeCAD UI. CadQuery removes the need for graphical UI entirely.

But this is not the whole picture. It's also possible to run FreeCAD without an UI, so I will have to dig deeper to really understand the tradeoffs between their two approaches. CadQuery actually started out as something built within FreeCAD. CadQuery became its own independent project when the team started feeling constrained by FreeCAD limitations around selection. That tells me CadQuery is working to get away from the well-known FreeCAD problem of topological naming.

Being code-centric means a CadQuery design is a Python program and can take advantage of all the software development tools available. Which satisfied my CAD wishlist item for Git-like ability to fork, pull request, etc. The problem is "diff", which will show the Python code changes but not a visual representation of those changes. This can probably be solved by using CadQuery to process the before/after views and render the difference between them. (Such a tool may already exist.)

Since CadQuery is not dependent on any graphical user interface, there are multiple ways to play with it. CQ-editor is a native desktop application letting people use CadQuery in a similar manner to OpenSCAD. Another way is to work with CadQuery Python code in a Jupyter notebook, giving it a browser-based interface. And the one that really caught my eye: cq-directive, which runs as part of the Sphinx documentation generator. In theory this allows diagrams in documentation to stay in sync with the CadQuery design files. Keeping CAD in sync with documentation would resolve one of my recurring headaches with Sawppy documentation.

CadQuery looks like a very promising venue for investigation, but trying to go hands-on was stymied by Python versioning support. As of this writing, the latest public version of Python is 3.11 and it's been around long enough most infrastructure like Jupyter Lab has updated. However, CadQuery is still tied to 3.10 and not expected to move up to 3.11 until later this year. Version conflict is nothing new in the Python world and can be solved with a bit of time, but I chose to put CadQuery on hold and read up on other options starting with Cascade Studio.