nlopt lacks wheels for Apple Silicon / Mac M1; dependency of cadquery can't pip install on Mac

[z3ugma]

Trying to use librepcb-parts-generator in a project on an m1 Mac fails because the version of nlopt is pinned to 2.71, which I think is because CadQuery is pinned very specifically at

librepcb-parts-generator/pyproject.toml

Line 10 in d31e8e5

"cadquery == 2.3.1",

"cadquery == 2.3.1",

uv add git+https://github.com/LibrePCB/librepcb-parts-generator.git
Resolved 47 packages in 630ms
error: Distribution `nlopt==2.7.1 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform

hint: You're on macOS (`macosx_15_0_arm64`), but `nlopt` (v2.7.1) only has wheels for the following platforms: `manylinux_2_17_x86_64`, `manylinux2014_x86_64`, `macosx_10_9_x86_64`, `win_amd64`; consider adding your platform to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

It looks like nlopt has newer wheels https://pypi.org/project/nlopt/#nlopt-2.9.1-cp39-cp39-macosx_11_0_arm64.whl so if we bumped cadquery, it may resolve the nlopt issue.

cadquery==2.5.2 and nlopt==2.9.1 work on MacOS.

Suggested fix is to not freeze the version so tightly, we could do cadquery ~=2, or cadquery ~=2.5

[ubruhin]

I don't think the pinning of cadquery is the problem, as far as I can see cadquery 2.3.1 does not require a particular version of nlopt.

But this hint in the error message is interesting:

consider adding your platform to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

I temporarily added this to pyproject.toml (copy&paste from UV docs):

[tool.uv]
# Require that the package is available for macOS ARM and x86 (Intel).
required-environments = [
    "sys_platform == 'darwin' and platform_machine == 'arm64'",
    "sys_platform == 'darwin' and platform_machine == 'x86_64'",
]

And as far as I can see, this creates a uv.lock with nlopt versions also available on Apple Silicon. Maybe this even doesn't need to be part of our pyproject.toml, but could be added to pyproject.toml of your project? I think usually the top-level project (the application) should commit the uv.lock file while libraries (like this repo) do not.

But I am not a pyproject.toml expert. @rnestler migrated this project to pyproject.toml, maybe he knows more.

[ubruhin]

That said, I agree bumping cadquery might still fix the problem too as the dependency resolver seems to use a newer nlopt version then. In general I'd accept a PR to bump the cadquery version but it should still point to a very specific version to get better reproducibility of 3D models. And it should be tested with a few scripts if they still run correctly and the generated STEP files are still correct.

[z3ugma]

In my own project:

uv add "git+https://github.com/LibrePCB/librepcb-parts-generator.git"
Resolved 48 packages in 545ms
Built librepcb-parts-generator @ git+https://github.com/LibrePCB/librepcb-parts-generator.git@d31e8e5837aad88776c7ebb523a5f6e1dfdfd68d
× Failed to build nlopt==2.6.2
├─▶ The build backend returned an error
╰─▶ Call to setuptools.build_meta:__legacy__.build_wheel failed (exit status: 1)

  [stdout]
  running bdist_wheel

I can see that it is now trying to resolve nlopt 2.6.2 after adding your suggested required-environments - so it tries to resolve an older version of nlopt

This wheel is failing to build for some reason, but I can troubleshoot that.

[z3ugma]

And it should be tested with a few scripts if they still run correctly and the generated STEP files are still correct.

The unit tests, using pytest, all pass with the higher version. Let me know if you feel like the unit tests need additional STEP file tests to make sure you feel confident that the STEP files are being produced as expected

[ubruhin]

Unit tests do not test 3D models at all (note that this is a developer tool, not a user-facing tool so the automated testing is more relaxed compared to the LibrePCB repository). 3D models are not even generated by default, only then the --3d flag is passed to scripts. So manual testing needs to be done by calling a few scripts with that flag and then randomly check a few STEP files in the output directory (open them e.g. in FreeCAD to see if they open & look correct).

[z3ugma]

Possible that #156 solves it, will test