Repository navigation
Experiment with uv #90
Description
uv is fast rising in popularity. It's written by Astral, the same folks behind ruff.
It does everything that Poetry does when combined with pyenv for Python installation, although its Python or even pyenv's may not be suitable for production use.
This experimentation should try swapping out poetry + pyenv in the Makefile to see what changes would be necessary.
I would not consider a wholesale switch until uv is 1.0.0, at which time I'd consider it with the values of
-
first-time setup performance
-
package installation performance (cold cache)
-
package update performance (hot cache)
-
availability of tooling replacements, e.g. diff-poetry-lockfile in our GitHub workflows
make-python-devex/.github/workflows/make-based-ci.yml
Lines 22 to 24 in 669a039
-
minimization of helper tasks e.g. poetry-venv-implode.
Lines 314 to 316 in 669a039
-
lockfile improvements (e.g. standardization track vs bespoke, diff-able, etc.)
-
others TBD
Activity
lucabotti commentedon Dec 26, 2024
Initial setup would reduce to uv installation as the only real dependency for the makefile (could be the init target).
After that, the pyproject.toml would be the only driver, given uv capability to install tools and python versions.
For the comment about uv python and production use - given the recent move of python build standalone (https://astral.sh/blog/python-build-standalone) , I tried to analyse this comment better. Also some comments from Python bytes clarified the situation, and this is not really the case - python build standalone removes some dependencies from the underlying OS and, in my humble opinion, could be better isolated (yes, in docker also) for production use.
lucabotti commentedon Dec 26, 2024
Additionally, check uv-migrator for migration of pyproject.toml
colindean commentedon Dec 27, 2024
Thank you for the input! This will be useful when undertaking this exploration.
lucabotti commentedon Dec 27, 2024
@colindean I am tempted to fork and submit a pull request, but my use case is different - I am Linux based, and checking the makefile your specific needs (macos, arm, data science) emerge, while I am more oriented to generic Python development. Not sure to be able to grant the specific needs - eg compilation flags - of your use case.
colindean commentedon Feb 17, 2025
Solid analysis and links to current ecosystem blockers in this: johnthagen/python-blueprint#238