cq_warehouse: The Hardware Store Hidden Inside CadQuery
A Python library that turns standards tables, fasteners, bearings, and threads into parametric solids, then reaches beneath CadQuery to patch in the missing industrial stuff.
cq_warehouse augments CadQuery with parametric parts - generated on demand - and extensions to the core CadQuery capabilities.
- cq_warehouse turns engineering standards into reusable solids, then leaves CadQuery free to focus on assembly and composition.
- Its real advantage is the separation between CSV-backed part data and the Python geometry that consumes it.
- The repo gets practical where CAD kernels get brittle, using lower-level extensions for text, projection, and stable booleans.
- For code-driven mechanical work, it replaces repetitive manual modeling with named, composable part factories.
cq_warehouse looks like a parts library. It is more interesting than that. The repo turns standards tables into reusable geometry, then reaches under CadQuery's high-level API to add the missing industrial conveniences: BOM counts, text embossing, curved-surface projection, and part families that behave like code, not clip art.
Why this feels like a hardware store, not just a library
The basic pain point is familiar to anyone who has modeled assemblies by hand. Standard hardware is everywhere, but it is still tedious to redraw a washer, a bearing, or a threaded fastener every time you need one. cq_warehouse treats those parts like inventory: named, parameterized, and ready to place.
That framing matters because it changes the unit of work. You stop thinking in sketches and start thinking in components, dimensions, and reuse. The result is less drafting, fewer one-off models, and more time spent on the parts that actually differentiate the product.
That line is the project in miniature. cq_warehouse does not replace CadQuery. It extends it, which is the more revealing choice. The library sits where standards data, part factories, and CAD ergonomics meet.
The real engine: standards in CSV, geometry in Python
The repository leans hard on a CSV-as-database pattern. Fasteners, bearings, sprockets, and related standards live in data files, while Python handles parsing, normalization, and shape construction. That keeps dimensional knowledge separate from geometric logic, which is exactly where a maintainable parts library should draw the line.
The practical payoff is flexibility. Imperial fractions, metric dimensions, and part variants can be updated without rewriting the geometry layer. The code can read a standard, decode it, and hand the numbers to constructors that know how to make the right solid.
This is why the project feels bigger than a catalog. It is a translation layer. Standards enter as messy real-world data, then emerge as parts that can be used in assemblies, exported to STEP or STL, and regenerated when the design changes.
The weird part is where it gets good
The most interesting file is not the part catalog. It is `extensions.py`. That is where cq_warehouse stops politely using CadQuery and starts extending it. The repo monkey-patches convenience methods onto `Assembly` and `Workplane`, then drops into OCP when CadQuery's surface area is not enough.
That matters because CAD kernels are forgiving only until they are not. cq_warehouse deals with the brittle edge cases directly: thread fading, text on curved surfaces, projection onto non-planar geometry, and helper methods that make assemblies easier to inspect and count. In other words, it does the unglamorous work that keeps parametric design from breaking on contact with reality.
Threads, bearings, sprockets: where parametric math meets manufacturing reality
The core primitives show the project at full strength. `thread.py` handles helical geometry and the fading logic that softens a thread end before the kernel can complain. `bearing.py` uses a template-like hierarchy for races and rollers. `sprocket.py` turns chain pitch and tooth count into actual radii instead of hand-wavy sketches.
The key detail is that the math is not treated as pure. The code makes room for manufacturing and kernel constraints, including the tiny offsets that help a union succeed when exact geometry would fail. That is the difference between a pretty formula and a tool people can ship with.
| Workflow | Standard parts | Boilerplate | Strength | Weak spot |
|---|---|---|---|---|
| GUI CAD | Placed from catalogs or modeled manually | Low at first, high at scale | Visual and familiar | Repetitive for recurring hardware |
| Raw CadQuery | Built from scratch in code | High | Fully parametric and scriptable | You still have to model every common part |
| cq_warehouse | Named constructors backed by standards data | Low | Repeatable, assembly-friendly, standard-aware | Depends on CadQuery and its kernel layer |
That comparison is the point. cq_warehouse does not try to beat a full CAD suite at being a full CAD suite. It removes the dull, standard-part work that slows code-CAD down, then leaves the rest of the assembly to CadQuery.
Why cq_warehouse matters for code-driven mechanical design
The project is quietly infrastructural. It bridges engineering standards, code-first geometry, and the low-level realities of the OCCT kernel without making the user live in any one of those layers for too long. That is a valuable pattern for mechanical software: keep the standards in data, keep the logic in Python, and keep the kernel hacks hidden until they are needed.
That is why cq_warehouse reads like a hardware store built into the language runtime. It makes standard parts feel native to the codebase, and that changes the economics of every assembly built on top of it.
