dependency of build123d inappropriately restricted to old version 0.7.0

[kcleung]

Currently, the version of build123d is restricted to version 0.7.0. However, build123d 0.8.0 has already been released in December 2024.

This will inappropriately force users to use the old version which is inferior.

Accordingly, the dependency should instead be changed to ">= 0.7.0" to allow use of versions higher than 0.7.0

[clairbee]

It was done intentionally since build123d 0.8.0 started using ‘numpy’ that is incompatible with the one used by cadquery. PartCAD currently depends on both cadquery and build123d which creates a lot of complications. We are currently working on dropping both dependencies.

[kcleung]

It was done intentionally since build123d 0.8.0 started using ‘numpy’ that is incompatible with the one used by cadquery. PartCAD currently depends on both cadquery and build123d which creates a lot of complications. We are currently working on dropping both dependencies.

Do you mean one of them has dependency of numpy 1.x?

In this case may be appropriate to submit an upstream issue to the offending library. Actually, for conda, the build123d-feedstock maintainer has already submitted an upstream issue to ezdxf-feedstock and request numpy to be upgraded to 2.x

In this case, are you referring build123d as the offending package?

[clairbee]

In this case, are you referring build123d as the offending package?

I’m not considering any of them as offending.
Build123d happens to make releases more often.
I’m not planning to lecture any of them on how, what and when to release.
I just plan to make PartCAD less dependent on both of them.

[kcleung]

Since partcad needs to support codes from build123d, cadquery and scad, it would need be able to be installed together with build123d, cadquery and scan packages simultaneously to allow the partcad installation to open build123, cadquery and scad packages. Very often, a project may require to use third party parts from different code-cad systems.

[clairbee]

Since partcad needs to support codes from build123d, cadquery and scad, it would need be able to be installed together with build123d, cadquery and scan packages simultaneously to allow the partcad installation to open build123, cadquery and scad packages. Very often, a project may require to use third party parts from different code-cad systems.

That's not entirely true.
That's true for OpenSCAD.
But that's a bit different for CadQuery and build123d scripts which are third party "Turing complete" code with their own dependencies.
While PartCAD can run CadQuery and build123d within the same Python environment ("pythonSandbox: none" in "~/.partcad/config.yaml"),
the default behavior is to create sandboxes where the python code gets executed.
Within those sandboxes, custom python versions and dependencies can be installed (see "pythonVersion" and "pythonRequirements" in "partcad.yaml", as well as "requirements.txt" in the package folder).
By default "conda" is used for creating sandboxes, but "pypy" and other methods are planned for adding security features in the future.

[clairbee]

Regarding the original concern of this issue, I'm trying to address it with #265 .
CadQuery was the easiest to drop.
It will take a little longer to drop build123d as it's currently used for assemblies.
But once CadQuery is out of the picture, the build123d version can be relaxed to let the users of other build123d versions to use PartCAD too.