Mause
dev: migrate from poetry to uv as project manager
Fixes #1239 This is a fairly straightforward translation.
I switched the backend from poetry-core to pdm-backend because PDM follows standards more. But the functionality either provides is basic enough that there really is no difference, I can stick with poetry if you want.
I also updated noxfile.py so that I can run it locally. I did this by making the github actions stuff a no-op if it can't be imported.
A few followup tasks that I would like to do after this PR lands:
- scrub the remaining references to python 3.8
- add tests for python up to 3.13 (ideally) or 3.12 (if 3.13 isn't working yet)
- Actually fix type hints so that mypy passes. Currently running mypy fails, we just don't see this in CI because in
pythonapp.yamlwe only run python 3.9 and 3.10, and in the noxfile we specify to only run mypy for 3.8
I meant in a general sense, PDM philosophy seems to be they prioritize standards more than poetry does. For example poetry came up with their own dependency specification format. For this specific case, as we use them just as a build backend, I don't actually know of any differences between them. Just in general am a little more trusting of PDM.
Looks like this requires some more work:
warning: `VIRTUAL_ENV=.nox/tests-3-9-sqlalchemy-1-3-duckdb-0-9-2` does not match the project environment path `.venv` and will be ignored; use `--active` to target the active environment instead
I meant in a general sense, PDM philosophy seems to be they prioritize standards more than poetry does. For example poetry came up with their own dependency specification format. For this specific case, as we use them just as a build backend, I don't actually know of any differences between them. Just in general am a little more trusting of PDM.
From what I recall, poetry predates most of those standards? Certain they predate the specification format, though they've since added support for the standard. Ultimately if nothing has changed, I'm okay with either