Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

291–300 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#291

Post by datadeft »

procaryote wrote: post #204
datadeft wrote: post #166

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

It's a lot harder to write rust than python.

If you check the TCO than probably it pays off. I am not sure about how much harder it is. I do not use lifetimes and I clone a lot. Still the performance and the reliability a Rust project has vs. Python is insane.

Re: A year of uv: pros, cons, and should you migrate

#292

Post by zahlman »

BiteCode_dev wrote: post #149
BeetleB wrote: post #44

It seems like uv doesn't target replacing pipenv...? No mention of it in their docs and there is an open Github issue about it. I have yet to learn uv, but I intend to. Still, having to ".venv/bin/activate" to activate the virtualenv is a lot less ergonomic than "pipenv shell".

You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.

How exactly does `uv` determine which is "the" venv? Is it simply based on the working directory like the `direnv`/`autoenv`/etc. workflows others are describing here?

It does seem like people have use cases for running code in a different environment vs. the one being actively used to develop the package.

Re: A year of uv: pros, cons, and should you migrate

#293

Post by antirez »

uv may be an improvement, but the Python packaging hell is a cultural problem that will not be solved without changing culture. And the main cultural issue is: 1. Depending on small and huge packages for trivial things. 2. A culture of breaking API compatibility. The two things combined create the mess we see.

Re: A year of uv: pros, cons, and should you migrate

#294

Post by dagw »

EdwardDiego wrote: post #248
zahlman wrote: post #239

Earlier quoted context omitted.

PEP 751 is defining a new lockfile standard for the ecosystem, and tools including uv look committed to collaborating on the design and implementing whatever results. From what I've been able to tell of the surrounding discussion, the standard is intended to address this use case - rather, to be powerful enough that tools can express the necessary per-architecture locking. The point of the PEP 723 comment style in th…

Your reply is unrelated to my query - is a uv lockfile able to handle multiple arches like a Poetry lockfile?

uv works like poetry, rather than pipenv, in this regards.

Re: A year of uv: pros, cons, and should you migrate

#295

Post by zahlman »

sieve wrote: post #269
zahlman wrote: post #266

Earlier quoted context omitted.

>Something to do with breakage in ABI perhaps. There is a "stable ABI" which is a subset of the full ABI, but no requirement to stick to it. The ABI effectively changes with every minor Python version - because they're constantly trying to improve the Python VM, which often involves re-working the internal representations of built-in types, etc. (Consider for example the improvements made to dictionaries in Python 3.…

Very different way of doing things compared to the JVM which is what I have most experience with. Was some kind of FFI using dlopen and sharing memory across the vm boundary ever considered in the past, instead of having to compile extensions alongside a particular version of python? I remember seeing some ffi library, probably on pypi. But I don't think it is part of standard python.

You can in fact use `dlopen`, via the support provided in the `ctypes` standard library. `freetype-py` (https://github.com/rougier/freetype-py) is an example of a project that works this way.

To my understanding, though, it's less performant. And you still need a stable ABI layer to call into. FFI can't save you if the C code decides in version N+1 that it expects the "memory shared across the vm boundary" to have a different layout.

Re: A year of uv: pros, cons, and should you migrate

#296

Post by dagw »

EdwardDiego wrote: post #234
BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

I come from the viewpoint that I don't want my build tool to install my Python for me. In the same vein, I don't want Gradle or Maven to install my JVM for me. In JVM land I use SDKMAN! (Yes, that's what the amazingly awesome (in the original sense of awe: "an emotion variously combining dread, veneration, and wonder") concretion of Bash scripts is called). In Python land I use pyenv. And I expect my build tool to re…

I expect my build tool to respect the JVM/Python versions I've set (looking at you Poetry...) and fail if they can't find them

For what it's worth, uv does this if you tell it to. It's just not the default behaviour. Uv and pyenv can easily be used together.

Re: A year of uv: pros, cons, and should you migrate

#297

Post by gkfasdfasdf »

I am a casual python user, and for that I love uv. Something I haven't quite figured out yet is integration with the pyright lsp - when I edit random projects in neovim, any imports have red squiggles. Does anyone know of a good way to resolve imports for the lsp via uv?

Re: A year of uv: pros, cons, and should you migrate

#298

Post by slightwinder »

zelphirkalt wrote: post #215
barosl wrote: post #43

A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…

Any flow that does not state checksums/hashsums is not ready for production and all but beautiful. But I haven't used uv yet, so maybe it is possible to specify the dependencies with hashsums in the same file too? Actually the order of import statement is one of the things, that Python does better than JS. It makes completions much less costly to calculate when you type the code. An IDE or other tool only has to chec…

> Why not have smaller venvs for separate projects?

Because they are annoying and unnecessary additional work. If I write something, I won't know the dependencies in the beginning. And if it's a personal tool/script or even a throwaway one-shoot, then why bother with managing unnecessary parts? I just manage my personal stack of dependencies for my own tools in a giant env, and pull imports from it or not, depending on the moment. This allows me to move fast. Of course it is a liability, but not one which usually bites me. Every some years, some dependency goes wrong, and I either fix it or remove it, but at the end the benefit I save in time far outweighs the time I would lose from micromanaging small separate envs.

Managing dependencies is for production and important things. Big messy envs is good enough for everything else. I have hundred of script and tools, micromanaging them on that level has no benefit. And it seems uv now offers some options for making small envs effortless without costing much time, so it's a net benefit in that area, but it's not something world shattering which will turn my world upside down.

Re: A year of uv: pros, cons, and should you migrate

#299

Post by tartieret »

BiteCode_dev wrote: post #283

Author here. A.m.a

Great overview thanks

I just reviewed uv for my team and there is one more reason against it, which isn't negligible for production-grade projects: Github Dependabot doesn't handle (yet) uv lock file. Supply chain management and vulnerability detection is such an important thing that it prevents the use of uv until this is resolved (the open github issue mentions the first quarter of 2025!)

Re: A year of uv: pros, cons, and should you migrate

#300

Post by zahlman »

datadeft wrote: post #290
zahlman wrote: post #286

Earlier quoted context omitted.

"It's written in Rust" is not responsible for most of the improvements on offer here. (TFA barely mentions Rust, to its credit.) Many of them come from algorithmic improvements, better design decisions, and simply just not having the tool reside in the same environment as the installation target. (It is perfectly possible to use Pip cross-environment like this, too. People just don't do it, because a) they don't know…

Do you think that pip could be re-implemented in Python and it would result in this performance that we are observing with uv?

I don't suppose it could be as fast as uv is, but it could be much closer to that than where it is now.

One immediate speed-up that requires no code changes: when uv creates a venv, it doesn't have to install Pip in that venv. You can trivially pass `--without-pip` to the standard library venv to do this manually. On my system:

  $ time uv venv uv-test
  Using CPython 3.12.3 interpreter at: /usr/bin/python
  Creating virtual environment at: uv-test
  Activate with: source uv-test/bin/activate

  real 0m0.106s
  user 0m0.046s
  sys 0m0.021s
  $ time python -m venv --without-pip venv-test

  real 0m0.053s
  user 0m0.044s
  sys 0m0.009s
For comparison:

  $ time python -m venv venv-test

  real 0m3.308s
  user 0m3.031s
  sys 0m0.234s
(which is around twice as long as Pip actually takes to install itself; I plan to investigate this in more detail for a future blog post.)

To install in this environment, I use a globally installed pip (actually the one vendored by pipx), simply passing the `--python` argument to tell it which venv to install into. I have a few simple wrappers around this; see https://zahlman.github.io/posts/2025/01/07/python-packaging-... for details.

In my own project, Paper, I see the potential for many immediate wins. In particular, Pip's caching strategy is atrocious. It's only intended to avoid the cost of actually hitting the Internet, and basically simulates an Internet connection to its own file-database cache in order to reuse code paths. Every time it installs from this cache, it has to parse some saved HTTP-session artifacts to get the actual wheel file, unpack the wheel into the new environment, generate script wrappers etc. (It also eagerly pre-compiles everything to .pyc files in the install directory, which really isn't necessary a lot of the time.) Whereas it could just take an existing unpacked cache and hard-link everything into the new environment.

Post reply on HN