Use uv for dependency/build management

[adrianschneider94]

I switched to uv for many internal projects and have had only the best experiences so far. Conda/Mamba could be dropped and installation with pip/any package manager with PEP517 would be easy.

[adam-urbanczyk]

Pip/uv/... are Python package managers and for a complex native dep stack you need a general package manager and a toolchain that everyone agrees on (something like conda|mamba+conda-forge fits the bill). Take a look here: https://pypackaging-native.github.io/

With that being said:

1. What is not easy about pip installation right now? AFAICT the wheel just works and you can use any package manager that uses pypi..
2. Are there any issues specific issues with conda/mamba? NB: you can just use micromamba (single executable) and simply run the thing without even touching your env.

[adrianschneider94]

There was an issue once (when Apple Silicon was not supported yet and I needed to get it working) where it was the easiest (for me) to switch to a PEP517 setup in the fork.
But when I last installed cadquery directly from github, everything went well. So that's fine for me.

I'd probably still advocate to migrate from setuptools to PEP 517/PEP 518 (pyproject.toml), as it is more common nowadays I think.

[jmwright]

There was a PR to add pyproject.toml in 2022, but our toolchain expects setup.py in spots, and there is logic in our setup.py that I do not think we can replicate directly with pyproject.toml. I do not think it's as fast/easy as just adding a pyproject.toml file.

[adrianschneider94]

Are there parts in the toolchain that are not part of the repo? I assume the logic you mention is this block?

cadquery/setup.py

Lines 26 to 36 in 8c68faa

	# Only include the installation dependencies if we are not running on RTD or AppVeyor or in a conda env
	if not is_rtd and not is_appveyor and not is_azure and not is_conda:
	reqs = [
	"cadquery-ocp>=7.8.1,<7.9",
	"ezdxf>=1.3.0",
	"multimethod>=1.11,<2.0",
	"nlopt>=2.9.0,<3.0",
	"typish",
	"casadi",
	"path",
	]

?

[adam-urbanczyk]

That is the logic. What is the problem you are trying to solve (NB: "x is more common than y" is not a problem), setup.py is not deprecated.

[adrianschneider94]

The problem I once had doesn't exist anymore. So there's no actual/immediate problem here - accordingly the discussion is closed.

The python packaging guide already strongly recommends a pyproject.toml (https://packaging.python.org/en/latest/discussions/setup-py-deprecated/) but of course it's no issue to wait with the migration until actual problems appear or setup.py is phased out.