Migrate to uv

[AlexanderWillner]

Goal

• As a developer
• I want to use proper tooling
• so that I can manage dependencies and the code

Suggested approach
In order to achieve this goal I suggest to use uv

Additional context
Over the last years multiple approaches in the Python ecosystem emerged (pip , pip-tools , pipx , poetry , pyenv , twine , virtualenv). Nowadays it seems uv is the best choice.

[mikez]

Nowadays it seems uv is the best choice.

[Citation needed] :)

The downside is it adds more dependencies (e.g. installing Rust toolchain). For complex projects this may make sense to get faster build speed, but here I think we want to keep dependencies minimal.

[mbhutton]

The downside is it adds more dependencies (e.g. installing Rust toolchain). For complex projects this may make sense to get faster build speed, but here I think we want to keep dependencies minimal.

Installing uv is very simple these days, no Rust toolchain required unless you want to build uv itself from source.
See https://docs.astral.sh/uv/getting-started/installation/
Eg installing via homebrew or via pip are both supported.

There isn't the usual tradeoff of adding complexity to get speed, it's very pleasant to use, and makes use of the pyproject.toml file. I find it much simpler to use than all the tools it replaces. The speed is a nice bonus.

[Citation needed] :)

It's a pity that uv came out after the PyCharm 2024 survey questions were finalised, otherwise we'd already have real numbers, but it did get a promising mention there.

In the meantime, eg comparing uv to poetry in stars (as flawed as that is): https://www.star-history.com/#python-poetry/poetry&astral-sh/uv&Date

[mikez]

@mbhutton Thanks for chiming in!

Installing uv is very simple these days, no Rust toolchain required unless you want to build uv itself from source.

Noted. 👍 It downloads a 16MB binary, it does not run from source. Thank you for helping me correct my assumption.

There isn't the usual tradeoff of adding complexity to get speed [...]

It sounds like the uv project has created a more beginner-friendly API/interface to interact with common Python tooling, especially managing packages. That does sound useful. I'm glad you're making me aware of this @AlexanderWillner and @mbhutton.

My comment here about complexity is that it adds a dependency on uv (a binary) by a for-profit company rather than using built-in community Python tooling. If there are strong benefits to using this, I'd be on board right away. However, since things.py is so minimal and has so few dependencies, I find adding this build dependency makes less sense from my experience — rather it adds a further maintenance burden (e.g. should uv inevitably as a venture-backed business try to monetize their software).

So in summary: uv has built a compelling interface to manage Python projects. In our case, I see no major benefit of using it; rather it adds a potential source of breakage in the future.

It's a pity that uv came out after the PyCharm 2024 survey questions were finalised, otherwise we'd already have real numbers, but it did get a promising mention there.

Thank you for trying to find citations. So far, I see no major Python project adopting this, which makes me think it isn't quite as mature or compelling yet for mainstream use. Again, from experience, I find it more helpful to keep build dependencies low unless there's a significant advantage. Otherwise, it adds more maintenance cost down the line.

I hope this makes sense.

[mbhutton]

@mikez Very much fair enough to want to avoid a dependency on a venture backed company! 🦅

Part of the appeal of uv for me was how it's very PEP 621 compatible by design, preferring everything to be defined in the pyproject.toml file, making it more straightforward to switch between uv and other PEP 621 packaging tools.

Migrating to another PEP 621 compatible tool such as Poetry could be another option at some point?

[mikez]

@mbhutton Thank you for the pointer to PEP 621. Using pyproject.toml seems like the future way to go.
In our case, what's the chief advantage of using Poetry, uv, or another PEP 621 compatible tool vs going with the built-in tools?

[mbhutton]

In our case, what's the chief advantage of using Poetry, uv, or another PEP 621 compatible tool vs going with the built-in tools?

In the case of uv: Easier, faster development. Less duplication of config (eg dependencies specified in one place rather than requirements.txt and setup.py). No need for manual creation and activation of venvs (all done automatically), and less cleanup when accidentally doing a pip install into the wrong python environment. Less need to keep track of when a redo of pip install is needed in case a dependency is updated, that sort of thing, which makes for a more enjoyable dev experience. Therefore potentially more contributions?

Tbh I'm not sure it makes sense to convert existing projects like this that already work well. I just saw the comments on uv above and wanted to make a case for trying uv out as a tool in general, as a quality of life improvement. It probably makes sense to try it out more generally first, possibly on a new project to see whether you even like it.

Even with the current structure of using the built-in tools, devs can use eg uv pip as a drop-in for pip, to see the joy of speed, as uv also understands the built-in config setups too.
Or by running something like uvx things-cli --version which let a user just run things-cli without needing to install it, taking care of setting up a venv, downloading all the deps, caching etc, so that running it the second time is even faster.

[mikez]

Thank you for claryfing. It sounds like uv is great for beginners who don't understand the Python (or UNIX) ecosystem well — one tool which does many things – "I just works (I don't care how)". For more experienced developers, I don't see how this eases development; especially with pyproject.toml. I very much enjoy the Unix philosophy of small tools which do one thing well — and the ability to create custom tools on the fly which automate things.

That said, build speed is still a massive benefit in projects that might benefit from it. However, in our case, that's no bottleneck. (Virtual environments are also no rocket science if you understand what it does behind the scenes.)

[mbhutton]

Totally agree with all of that! Long reply below to the inferred question of [how does this help experienced developers].

Composable unix tools are great, I enjoy automating things too! Where possible I try to script at the highest layer available, to have less code to maintain.
And yes, virtual environments are brilliant and are a simple and well implemented idea. I try to keep every tool in a separate venv whenever possible one way or another.

Also agree that it's not necessary to adopt uv, and that the speed benefit is small for this project, and there's also some benefit to sticking with the built-in tooling.

To answer your question:

..is great for beginners.. For more experienced developers, I don't see how this eases development

For all developers, including devs who know how to use the built-in tools: less steps to achieve the same goal, and less state to manage, leaving more time and headspace to concentrate on improving the code itself.

Eg how many steps would it take to:

• (a) Clone a copy of this project and make and test a quick fix, and submit it, and clean things up once done
• (b) Test this tool across different versions to see when a bug was introduced (including dependency changes)
• (c) Try out this tool in a reversible way that doesn't leave behind dependencies

Both (b) and (c) can thankfully be done using uv already with no project changes required. Switching to pyproject.toml would make (a) slightly easier, as a small benefit.

All of the above can be done manually or using bespoke scripts, and all are easier and faster to do (with less steps) if scripting on top of something like uv. For me it's the abstraction layer that I no longer need to write because it does exactly what I'd automate if I had the time.

I think of it as a higher level abstraction over the standard tooling, all of which is still there and available. It covers 90% of what I need, so I only have to script the 10% that's specific to me.

It's the same benefits as from something like homebrew+Brewfiles (compared with building from source), or using Git porcelain commands rather than Git plumbing commands, or using an existing dotfile manager like Chezmoi or GNU stow, or even parts of Nix. Anything which automates away lower level hassle so that I can get more done in less steps.

There's a spectrum of [use built-in tools and lowest common denominator like POSIX,bash3,setuptools] <--> [use the new hotness for a nicer experience like fish,nushell,uv,ripgrep,bat,atuin etc], where there are clear tradeoffs of each.

I envy people who can be on the left side of that spectrum and be satisfied, as it probably saves a lot of time researching and switching new tools, which is also precious developer time! I'm on the other end mainly because I get frustrated by any tool which I know could be better.

Which is all just to say: it's a very nice tool, is well aligned with the standard Python tooling, is IMO easier to script with, and I really like it!

I think that's as much of a case as I can make for the tool itself, so I'll get back to developing with both uv and this wonderful things.py library, both excellent tools that I'm grateful for! :)

[mikez]

@mbhutton Thank you for your generous time in sharing your thoughts. I like living on the right edge: I use ripgrep and bat. :)
Build tools are different for me, since they're the foundation for everything else. Here I like to be on the left edge... since (from experience) maintenance becomes very costly in the long run. — That said, your cases a-c sounds like one-offs that individual contributors could make use of and doesn't require uv to be required for things.py.

[mikez]

@mbhutton Brief follow-up. As I emailed Armin for an unrelated issue, I checked out his recent projects, discovered rye... and then saw that rye had turned into uv. :) Now I get the origin of this project: it's Rust's Cargo reimagined for Python. I suspect that if this project becomes more stable (and viable), then aspects of this might find itself back into standard Python.