CadQuery Comes of Age | Hacker News Reader

CadQuery Comes of Age

hackaday.com

63 pointswatchdogtimer28 comments

If it's only distributed by anaconda, it's a hard "no" for me, since anaconda breaks existing libraries. I mean I could play with miniconda, but really, a docker container / flatpak would be better suited. And if I have to spend hours to try to get something to work, it's usually not worth the sunk time.

See here for the discussion.

https://github.com/CadQuery/cadquery/issues/153

I agree with you. That's why in the past I made this issue: https://github.com/CadQuery/cadquery/issues/153

The developers don't seem to be receptive. But fortunately a nix flake exists: https://github.com/marcus7070/cq-flake

Takes ages to compile thought so I advice you to either be patient or add the cache.

I tried CADQuery in the past, but struggled with the setup. With a very limited python background, it was suprisingly difficult to understand what prerequisites are required.

I already have python installed. Why do I need anaconda? What is anaconda? "A data science toolkit" (from their website) ? Why do I need that? Why can't I just "pip install cadquery" and expect it to work?

It turns out conda is an alternative package manager for python, and cadquery is only distributed via conda, not pip. I'm surprised this basic bit of information is (still) not explained in the docs.

The issue you created finally explained _why_ to me, so thanks for that :)

The problem is that cadquery depends on OpenCascade Technology (OCCT), a 3D geometry library. A full build is ~1.5GB, and it is the reason why the download for CadQuery is so big. PyPI is not meant for such large packages, and currently has no mechanism to allow for out of bounds binary downloads.

OCCT is both large and also takes a long time to compile. With conda-forge there is a good mechanism for CI/CD builds of this complexity. Other OpenCASCADE-based python modules (pythonOCC for ex) are also on conda for similar reasons, so from an ecosystem point of view it makes sense. Given that developers have limited time I understand that they rather work on features than fighting with the various build systems and python package managers, and simply choose what's most appropriate on paper.

That said, if you need to mix various modules on conda it can really be a challenge to find a conflict-free configuration, I agree.

Yeah I was reading that thread. I appreciate you opening it, frankly.

They are pretty hostile to pypi devs with regards to the fact they were asking pypi to distribute their 1Gb+ python packages, rather than trying to modularize their packages to make it easier to distribute.

https://github.com/CadQuery/cadquery/issues/153#issuecomment...

NLTK has a method so the library can be installed through pypi and the data can be downloaded through the following method:

    import ntlk
    ntkl.download()

So given what I've been reading about cadquery the less and less I want to deal with their software.

It pains me to say this but you are right on that front. The software itself is amazing to use though.

Fun fact, cq-editor does actually work in Docker. I haven't tested autoreloading, but the app at least launches and renders fine, "just" needed to configure X.org proxying or whatever it's called. Thankfully I ended up not needing such a setup.

Cadquery works fine for me in its own separate miniconda environment. The full anaconda is not needed. If dependency resolution fails or is slow, I suggest using mamba for the cadquery / cq-editor install commands – way faster and more reliable.

I'm sure you know this if you use CadQuery, just saying it for the rest of the crowd.

Awesome. But it's not really great software if the packaging isn't reliable, is it?

"Look how easy it is. All you need to do is to do is to install miniconda, and wait for it to download 1GB of software. Hope it doesn't break any installed pythons or your pythonpath or any existing packages!"

I'm not sure why miniconda would break your existing python setup? It installs all packages in a separate environment, that's its main purpose.

I don't know why Conda / CadQuery dependencies are so big, but I have more than enough space for them.

Python is far from my favorite language, both in terms of coding and setting it up, but we're not exactly swimming in open source programmable[1] CAD solutions. There's OpenSCAD which is more limited, there's JSCAD that I haven't tried, and... that's pretty much it? CadQuery seems to be the most mature option from my limited experience, despite the annoyance with conda.

[1] I'm aware that some visual CAD apps like FreeCAD have some scripting / plugin support, but it's not the same when this coding isn't the primary building interface, and those apps all have their own (significant) issues anyway.

> I'm not sure why miniconda would break your existing python setup? It installs all packages in a separate environment, that's its main purpose.

Neither am I, nor do I want to find out if it does, given their poor track record of messing with PATH and pythons and stuff.

I swore I saw docker images mentioned in their docs when I looked the other day?

I haven't seen anything yet. And I'm not going to download 1GB of data to deal with a possibly shitty api/app/program when a fraction of that would suffice.

CadQuery is awesome. When I was designing my keyboard[1] the original version was a huge mess of OpenSCAD. Transitioning to CadQuery simplified the code a lot and let me produce the STEP files CNC machines need instead of the rendered STLs OpenSCAD is only capable of.

[1] https://github.com/ecopoesis/nek-type-a

First comment on hackaday is "a one gig installer? no thank you".

Exactly the first reason why I don't consider cadquery a viable tool (not the only one): conda is a monstrosity (even miniconda) that will irrevocably maim your system if you're crazy enough to install it.

Another reason is this: selecting a subcomponent in a complex hierarchical model is basically a nightmare:

https://github.com/dcowden/cadquery/issues/29

That seems a pretty old issue on a read-only repository. Is it still a problem today?

All this talk about anaconda etc is a little overblown. Just grab the release ZIP here and run the launcher. It drops you in the editor/debugger workspace with full functionality. https://github.com/CadQuery/CQ-editor/releases/tag/0.2 It doesn't appear to modify your system in any way.

I understand that other modes of using CadQuery require 'conda, but the basic built-in editor experience is self contained. Or am I misunderstanding something?

Unfortunately the latest published version, 0.2, is pretty old, and lacks newer features such as autoreloading imported modules for example, which imo is a must for any sizeable project.

That said, for me the miniconda setup was annoying but not too hard. Wouldn't say it's the worst part.

Learning the concepts and APIs with no prior 3D experience is a lot harder. Results are worth it though.

dropping into the built product like that fundamentally misunderstands why we even want to be using a really language like python. CQ editor is really good. and using it for an hour just makes me want vscode back.

is there any programming style for it which doesn't look like some crazed 90s java, with all the method chains?

something with contexts would be nice, maybe?

with cq.Workplane("XY").box(h,w,t) as plate: plate.faces(">Z").workplane().hole(diameter) show_object(plate)

there's got to be some compromise between the explicitness of cadquery, and the implictness of openscad.

What’s crazy about it? And how would contexts by more ergonomic than method chaining? Hard to imagine honestly.

You can always use intermediate variables if you want to.

I generally dislike fluent interfaces too, so much so that it stopped me from trying CadQuery initially. Only once I encountered something I couldn't do with OpenSCAD did I give it a go and now it's the only tool I use. It is one of the rare cases where fluent works very nicely.

Because it's python, you can always use parentheses to split long lines neatly.

and IMO that should be the default example not using escapes \

Indeed. It's pretty widely accepted in the Python world that \ should never be used. Black for example zealously removes them. Perhaps if we ever get a Python 4, it can actually be removed (along with other minor annoyances like the camelCase in the logging library!).

There are actually at least two styles that do exactly that. They are called OpenSCAD and JSCAD. The code above would be simple subtract(cube([h,w,t]), translate([h/2,w/2,t], cylinder({radius, height})))

I don't know why the article makes it sound like cadquery is superior in every way possible. Sure BREP is a lot more powerful than CSG, but with extra power comes extra learning curve. If all you ever design is 3d prints for reprap (and I'd guesstimate 95% of hackaday audience falls into that category) cadquery may be an overkill

i'm perfectly aware of openscad, i literally referenced it in my question.

you've completely wasted both our times.

> there's got to be some compromise between the explicitness of cadquery

Most cadquery examples are hard to follow due to context implicitness. They are basically write only.

Using cadquery for some parts but still need openscad for other parts, reason is didn't find how to make a "hull" in cadquery. Is there the equivalent of openscad hull in cadquery?

Can’t wait to BIM on it one day.

Reply on news.ycombinator.com