Last week, I started developing directly in PyTorch containers using just pip and Docker. With GPU forwarding on Windows no longer being such a hassle, I'm really enjoying the setup. Still, I can’t shake the feeling that I might be overlooking something critical.

I’d love to hear what the HN crowd thinks about this type of env.

Kudos to the uv developers for creating such an amazing piece of software!

uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

uv felt a bit immature at the time, but sounds like it’s way better now. I really want to try it out... but Poetry just works, so I don’t really have an incentive to switch just yet. (Though I’ve switched from FlakeHeaven or something to Ruff and the difference was heaven and hell! Pun in’tended.)

Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.

That's always one major thing I saw breaking old builds: old binaries stop being hosted, forcing you to rebuild them from old source, which no longer builds under current toolchains - making you either downgrade the toolchain that itself may be tricky to set up, or upgrade the library, which starts a cascade of dependency upgrades.

It's not like Node projects are distributed with their deps vendored; there's too much stuff in node_modules.

Yes you can find edge cases with problems. Using this as an argument for "breaks 3 times per week" does not hold.

(Also note that outside the web/mobile space, projects that weren't updated in a year are still young, not old. "Old" is more like 5+ years.)

The two things are related. If your typical project has a dependency DAG of 1000+ projects, a bug or CVE fix somewhere will typically cause a cascade of potentially breaking updates to play out over multiple days, before everything stabilizes. This creates pressure for everyone to always stay on the bleeding edge; with a version churn like this, there's only so many old (in the calendar sense) package dists that people are willing to cache.

This used to be a common experience some years back. Like many others, I gave up on the ecosystem because of the extreme fragility of it. If it's not like that anymore, I'd love to be corrected.

And what if there are no binaries yet for my architecture, will it compile them, including all the dependencies written in C?

Instead there is pixi, which is similar in concept to uv but for the conda-forge packaging ecosystem. Nix and guix are also language-agnostic package managers that can do the job.

If you want to build shapely against your own version of GEOS, then you fall outside of what uv does. What it does in that case is download the all build tool(s) specified by shapely (setuptools and cython in this case) and then hands over control to that tool to handle the actual compiling and building of the library. It that case it is up to the creator of the library to make sure the build is correctly defined and up to you to make sure all the necessary compilers and header etc. are set up correctly.

But conda-forge packages (just like PyPI packages, or anything that does install-time dependency resolution really) are untestable by design, so if you care for reliably tested packages you can take a look at nix or guix and install everything through that. The tradeoff with those is that they usually have less libraries available, and often only in one version (since every version has to be tested with every possible version of its dependencies, including transitive ones and the interpreter).

All of these tools have a concept similar to environments, so you can get the right version of GEOS for each of your projects.

Nix/guix sound interesting. But one of my systems is an nVidia Jetson system, where I'm tied to the system's libc version (because of CUDA libraries etc.) and so building things is a bit trickier.

[1]: https://github.com/spack/spack/blob/develop/var/spack/repos/... [2]: https://github.com/spack/spack/blob/develop/var/spack/repos/...

On Alpine and Arch Linux? Exactly nothing.

On Debian/Ubuntu? maybe the convoluted packaging process, but that's on you for choosing those distributions.

    uv build
    Building source distribution...
    running egg_info
    writing venv.egg-info/PKG-INFO
    Successfully built dist/venv-0.1.0.tar.gz
    Successfully built dist/venv-0.1.0-py3-none-any.whl

uv init

uv sync

and you're done

I'd say if you do not run into the pitfalls of a large python codebase with hundreds of dependencies, you'll not get the bigger argument people are talking about.

That said, I do wish uv had `uv activate`. I like just working in the virtualenv without having to `uv run` everything.

I was heavily invested into virtualenv until I had to upgrade OS versions, which upgraded the Python versions and therefore broke the venvs.

I tried to solve this by using pyenv, but the need of recompiling Python on every patch wasn't something which I would accept, specially in regards to boards like Raspberry Pis.

Then I tried miniconda which I initially only liked because of the precompiled Python binaries, and ultimately ended up using pyenv-managed miniforge so that I could run multiple "instances" of miniforge and therefore upgrade miniforge gradually.

Pyenv also has a plugin which allows to set suffixes to environments, which allows me to have multiple miniforges of the same version in different locations, like miniforge-home and miniforge-media, where -home has all files in the home dir and -media has all files on a mounted nvme, which then is where I put projects with huge dependencies like CUDA inside, not cluttering home, which is contained in a VM image.

It works really great, Jupyter and vscode can use them as kernels/interpreters, and it is fully independent of the OS's Python, so that OS upgrades (22.04 -> 24.04) are no longer an issue.

But I'm reading about all these benefits of uv and wish I could use it, but somehow my setup seems to have tied my hands. I think I can't use uv in my projects.

Any recommendations?

Edit: Many of my projects share the same environment, this is absolutely normal for me. I only create a new environment if I know that it will be so complex that it might break things in existing environments.

It's not that uv is not an option for me, I made this move to miniforge before uv was on my radar because it wasn't popular, but I'm still at a point where I'm not sure if uv can do what I need.

https://docs.astral.sh/uv/pip/environments/

I think uv supports conda envs

- uv init new-py-env

- cd new-py-env

- uv add jupyter

- uv build

These are executed super fast. Not sure if this could help your situation but it is worth to be aware of these.

I've got a couple quite big Django projects for which I've used venv for years, and not once have I had any significant issues with it. Speed at times could have been better and I would have liked to have a full dependency list lock file, but that never caused me issues.

The only thing that comes to mind is those random fails to build of C/C++ dependencies. Does uv address this? I've always seen people rave about other benefits.

I often use Python for quick one off scripts. With UV I can just do `uv init`, `uv add` to add dependencies, and `uv run` whatever script I am working on. I am up and running in under a minute. I also feel confident that the setup isn't going to randomly break in a few weeks.

With most other solutions I have tried in the Python ecosystem, it always seemed significantly more brittle. It felt more like a collection of hacks than anything else.

https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

That plus this: https://news.ycombinator.com/item?id=42855258

Makes it pretty seamless for one-off scripts.

We recently switched to PDM in our company because it worked very well in our tests with different package/dependency managers. Now I am rethinking if we should switch to uv while PDM usage is still not very wide-spread in our company. But PDM works very well, so I am not sure whether to keep using it.

Doesn’t make pdm bad in itself but that means there’ll be fewer pdm users around to report bugs, potentially fewer contributors to it too, fewer resources, etc.

I wonder what it would take to get poetry on par with uv for those who are already switching to it? Poetry is definitely very slow downloading multiple versions of packages to determine dependencies (not sure how uv works around this?). Does uv have a better dependency checker algorithm?

Different laws of physics, to start with.

I've been working with pip for so long now that I barely notice it unless something goes very wrong.

- uv can install python and a virtualenv for you. Any command you run with `uv run` from the root of a repo will be aware of its environment, you don't even need to activate a virtualenv anymore. This replaces {pyenv, pyenv-virtualenv, virtualenvwrapper,...}.

- uv follows the PEPs for project config (dependencies, optional dependencies, tool configs) in the pyproject.toml so in case uv dies, it's possible to migrate away for the features are defined in the PEPs. Which is not the case for say, poetry.

- uv has a lock file and it's possible to make deps platform specific (Windows, Linux, MacOS, etc). This is in compliance with a PEP but not supported by all tools.

- uv supports custom indexes for packages so you can prefer a certain index, for example your company package index or pytorch's own index (for ML work).

- very fast, makes local dev very seamless and is really helpful in CI/CD where you might just setup and tear down python envs a lot.

Also, the team is responsive on Github so it's easy to get help.

With how much the ecosystem is moving, I don't know whether the way we're doing it is unusual (Django and some other big projects still have a tox.ini), obsolete (I can't find how ux obsoletes this), or perfectly fine and I just can't find how to replace pip with ux for this use case.

I don't think there's a definite answer yet.

You don't need `pyenv`, `poetry` and `pipx` anymore, `uv` does all of that for you.

It's a much more complete tool than pip. If you've used poetry, or (in other languages) cargo, bundler, maven, then it's like that (and faster than poetry).

If you haven't, in addition to installing dependencies it will manage and lock their versions (no requirements.txt, and much more robust), look after the environment (no venv step), hold your hand creating projects, and probably other things.

Edit to add: the one thing it won't do is replace conda et al, nor is it intended to.

The td;rd is that is has a lot less modes of failure.

I work in a place with 200 developers, and 99% of pip usage is in automated jobs that last an hour. Shaving a couple seconds off that will not provide any tangible benefit. However moving 200 people from a tool they know to one they don’t comes at a rather significant cost.

I intend to use system python there but previously poetry will simply crash the whole Pi while installing itself.

uv tool is also a great replacement for pipx.

I think it's the way to go for Python dependency management in 2025.

Ruff for me meant i could turn 4 pre-commit hooks (which you have to configure to be compatible with each other too) into just 1, and i no longer dread the "run Pylint and take a coffee break" moment.

I jumped ship to UV recently. Though i was skeptical at first i don't regret it. It makes dependency management less of a chore, and just something i can quickly do now. Switching from Poetry was easy for me too, only package i had issues with was pytorch, but that just required some different toml syntax.

(1) As uv’s governance is driven by a for-profit company, I see incentives that will eventually compromise on its benefits.

(2) Python packaging has historically been very fragmented, and more recently there’s been lots of work on standardization. That work will be impacted when users massively shift to one package installer.

Neither of those things are clear negatives, but they’re worth being aware of.

[0] https://pdm-project.org

UV does not solve all the hard problems.

Maybe switch to Pixi?

Took a huge chunk of complexity out of bootstrapping projects which I was otherwise handling myself.

It'd be nice if we could have a shim for `uv` that allows it to play nice with `asdf` (there is an `asdf-uv` but seems to be about installing different versions of `uv` when instead I want to install different versions of python _via_ uv).

I've had it with version managers that only target a single language or tool, the cognitive load is too high if there's more than a couple of languages in the mix.

What would be really nice is an asdf-like single package manager with language-specific plugins. That would save me a bunch of headaches.

I was one of the last holdouts, preferring to keep 2.7 support if it wasn't too much hassle, but we have to move on at some point. Fifteen years is long enough support.

But being written in Rust means I'm having to also finally get somewhat proficient in Rust. Can any Rust developers comment on the quality of the uv codebase? I find it surprisingly procedural in style, with stuff like hundreds of `if dry_run` type things scattered throughout the codebase, for example. Is this normal Rust style?