6 ms·

uv is the backbone of any modern Python library. I’m excited to see improvements. https://stephenlf.dev/blog/python-library-in-2026/ https://stephenlf.dev/blog

uv is the backbone of any modern Python library. I’m excited to see improvements. https://stephenlf.dev/blog/python-library-in-2026/ https://stephenlf.dev/blog/python-library-in-2026/

310298 17d ago
Nonsense. uv is one of many existing build tools. All the items can be done by other programs. Funny to list OpenAI as an example at the end of the blog post ...
tingletech 17d ago
they just implement the modern PEPs
- woodruffw 16d ago
  We do a lot more than that, e.g. how to cache distributions is not defined anywhere within PEPs (and should not be, since it’s a purely internal tool decision). But yes, it helps that uv implements the PEP for detached metadata, particularly during resolution.
  - tingletech 16d ago
    Don't get me wrong, I love `uv` -- I mean as far as being "the backbone of any modern Python library" -- shouldn't any modern python library work with any packing system that follows the PEPs?
    - woodruffw 16d ago
      It depends on what you mean. The PEPs are essentially a behavioral core, and each tool (build backend, etc.) adds on top of that core. If you’re installing a package, any installer should work; if you’re developing a package, you may be subject to implementation details from your development tool of choice.
      - tingletech 13d ago
        "backbone" is what has me hung up, seems more like a scaffold or maybe a bionic exoskeleton.
marknsikora 17d ago
Good article. But the Makefile part should really be replaced by tox as a best practice. Tox even has a uv runner now that will handle setting up all the environments.
- zbentley 17d ago
  There’s a bit of a bootstrap problem there in that Tox (and its dependencies) have to be installed first, unless your makefile is calling “uv run tox” or similar. Uv’s standalone nature makes it ideal for bootstrapping projects in a way that tox isn’t.
- Zizizizz 16d ago
  I like just or mise tasks as often my python projects contain many other language commands (SQL, docker, pnpm, etc ...).
  - Timon3 16d ago
    IMO mise tasks are fairly close to the ideal polyglot task runner, because features like argument definitions can be used as progressive enhancements. That means I can write the task logic in shell scripts that can be called without mise, and when I integrate them into mise, I don't have to manually write extra wrappers or duplicate anything. That's my pet peeve with most similar tools, so I can't recommend mise enough!
- appplication 16d ago
  Strong disagree on tox. I was all in on it back in 2020-2023 and I found it was a consistent source of headaches and complexity. Whenever we’d run into venv issues it was always tox, often passing or not passing some critical under-the-hood ENV var resulting in reproducibility errors that were difficult to immediately diagnose. It also blurs the line between env vars used to set up tox env and those you want set in your final test env. We just use containers in CI instead now for matrix testing and it’s so much more clear what is going on with the test env.
1aj-187 17d ago
Can uv even be used with C extensions now?
- zbentley 17d ago
  It always could.
  - insane_dreamer 16d ago
    not sure it always could. we had to continue using conda for binary packages like cudann, or anything where a wheel wasn't available (nvidia now has Jax-compatible wheels for cuda packages, but it didn't before)
    - ketozhang 16d ago
      You're asking for something different here. What conda does is package all binary dependencies (e.g., libpq, cuda) that normally should be dynamically linked and provided by your OS. The pip ecosystem (including uv) doesn't encourage this. Although you could and many have, the build tools don't support it as first class. For why? Ask what happens if you want an updated version or specific version of CUDA? The library author must add support for runtime linking or users would have rebuild the entire conda package.

uv is the backbone of any modern Python library. I’m excited to see improvements. https://stephenlf.dev/blog/python-library-in-2026/ https://stephenlf.dev/blog/python-library-in-2026/

310298 17d ago

Nonsense. uv is one of many existing build tools. All the items can be done by other programs. Funny to list OpenAI as an example at the end of the blog post ...

tingletech 17d ago

they just implement the modern PEPs

woodruffw 16d ago
We do a lot more than that, e.g. how to cache distributions is not defined anywhere within PEPs (and should not be, since it’s a purely internal tool decision). But yes, it helps that uv implements the PEP for detached metadata, particularly during resolution.
- tingletech 16d ago
  Don't get me wrong, I love `uv` -- I mean as far as being "the backbone of any modern Python library" -- shouldn't any modern python library work with any packing system that follows the PEPs?
  - woodruffw 16d ago
    It depends on what you mean. The PEPs are essentially a behavioral core, and each tool (build backend, etc.) adds on top of that core. If you’re installing a package, any installer should work; if you’re developing a package, you may be subject to implementation details from your development tool of choice.
    - tingletech 13d ago
      "backbone" is what has me hung up, seems more like a scaffold or maybe a bionic exoskeleton.

marknsikora 17d ago

Good article. But the Makefile part should really be replaced by tox as a best practice. Tox even has a uv runner now that will handle setting up all the environments.

zbentley 17d ago
There’s a bit of a bootstrap problem there in that Tox (and its dependencies) have to be installed first, unless your makefile is calling “uv run tox” or similar. Uv’s standalone nature makes it ideal for bootstrapping projects in a way that tox isn’t.
Zizizizz 16d ago
I like just or mise tasks as often my python projects contain many other language commands (SQL, docker, pnpm, etc ...).
- Timon3 16d ago
  IMO mise tasks are fairly close to the ideal polyglot task runner, because features like argument definitions can be used as progressive enhancements. That means I can write the task logic in shell scripts that can be called without mise, and when I integrate them into mise, I don't have to manually write extra wrappers or duplicate anything. That's my pet peeve with most similar tools, so I can't recommend mise enough!
appplication 16d ago
Strong disagree on tox. I was all in on it back in 2020-2023 and I found it was a consistent source of headaches and complexity. Whenever we’d run into venv issues it was always tox, often passing or not passing some critical under-the-hood ENV var resulting in reproducibility errors that were difficult to immediately diagnose. It also blurs the line between env vars used to set up tox env and those you want set in your final test env. We just use containers in CI instead now for matrix testing and it’s so much more clear what is going on with the test env.

1aj-187 17d ago

Can uv even be used with C extensions now?

zbentley 17d ago
It always could.
- insane_dreamer 16d ago
  not sure it always could. we had to continue using conda for binary packages like cudann, or anything where a wheel wasn't available (nvidia now has Jax-compatible wheels for cuda packages, but it didn't before)
  - ketozhang 16d ago
    You're asking for something different here. What conda does is package all binary dependencies (e.g., libpq, cuda) that normally should be dynamically linked and provided by your OS. The pip ecosystem (including uv) doesn't encourage this. Although you could and many have, the build tools don't support it as first class. For why? Ask what happens if you want an updated version or specific version of CUDA? The library author must add support for runtime linking or users would have rebuild the entire conda package.