11 ms·

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

723 points by bertdb 2y ago

IshKebab 2y ago
Yes. Python tooling has been shit for decades and `uv` is actually good.
xyse53 2y ago
Adding to the article (which I agree with): Lack of `uv pip install --user` has made transitioning our existing python environment a bit more challenging than I'd like, but not a deal breaker.
- edudobay 2y ago
  Out of curiosity, how does `--user` fall in your use case? It got me confused because this flag makes it install to a central location within the user home directory and not to a virtual environment.
pityJuke 2y ago
uv is overposted as hell, but oh my god I love it so much I understand every single one of these posts. Simple things just work so effectively.
serjester 2y ago
I think at this point, the only question it remains is how Astral will make money. But if they can package some sort enterprise package index with some security bells and whistles it seems an easy sell into a ton of orgs.
- BiteCode_dev 2y ago
  Charlie Marsh said in our interview they plan to compete with anaconda on b2b: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-the https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th... Make sense, the market is wide open for it.
NeutralForest 2y ago
uv is so much better than everything else, I'm just can't afraid they can't keep the team going. Time will tell but I just use uv and ruff in every project now tbh.
- kyawzazaw 2y ago
  really need them to keep going the amount of people who switch to R because Python is too hard to setup is crazy high. Especially among the life scientists and statisticians
belval 2y ago
> I had a friend who decided to not use uv, because the first time he used it, it was on a 15 years old codebase that had just been migrated to Python 3. It was standing on a pile of never cleaned up pip freeze exports, and uv could not make it work. This is my only gripe with uv, despite how the author decided to depict it, this really turns into a headache fast as soon as you have ~4-5 in-house packages. I don't think it's that bad that uv is so unforgiving in those case because it leads to better overall project quality/cohesion, but I wish there was a way to more progressively onboard and downgrade minor version mismatch to warnings.
- code_biologist 2y ago
  Did they run into a hard blocker, or was it just that using version overrides was possible but painful? I started looking seriously at uv/pdm once poetry made it entirely clear they didn't intend to support version overrides [1]. uv's support for overrides seems serviceable if unsophisticated [2][3]. [1] https://github.com/python-poetry/poetry/issues/697 https://github.com/python-poetry/poetry/issues/697 [2] https://docs.astral.sh/uv/concepts/resolution/#dependency-overrides https://docs.astral.sh/uv/concepts/resolution/#dependency-ov... [3] https://docs.astral.sh/uv/reference/settings/#override-dependencies https://docs.astral.sh/uv/reference/settings/#override-depen...
  - aaravchen 2y ago
    The linked poetry Issue is pretty understandable why they aren't going to support it. I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency. Point blank, that's a packaging failure and the solution is, and always has been, to immediately yank the offending package. That said, the Python case has pretty limited ability to specify dependency package versions, which makes it nigh impossible to handle it downstream by blocklisting specific versions from an otherwise contiguous range. Take for example the werkzeug package that released a breaking API regression in a patch release version. It didn't affect everyone, but notably did affect certain Flask(?) use cases that used werkzeug as a dependency. In a sane system, either werkzeug immediately removes the last released version as buggy (and optionally re-releases it as a non-backwards compatible SemVer change), or everyone starts looks for an alternative to non-compliant werkzeug. Pragmatically though, Python dependency specification syntax should have a way for Flask to specify, in a patch release of its own, that werkzeug up to the next minor version, _but excluding a specific range of patch versions_, is a dependency. Allowing them to monkey patch the problem in the short term. It should never be on the end user to be specifying overrides of indirect dependency specifications at the top level though, which is what was requested from the poetry tool.
3l3ktr4 2y ago
I thought this was going to be about the UV rays from the sun... But it's another python package manager. We're running out of names.
- teraflop 2y ago
  I assumed it was going to be about libuv, the event loop library that Node uses.
- __MatrixMan__ 2y ago
  Were you considering migrating to ultraviolet light? Vitamin D is indeed important, but that mutagenesis is no joke. I'd suggest against it.
  - userbinator 2y ago
    I read it as "should you migrate to a more or less sunny region".
- paulddraper 2y ago
  I think you mean running out of acronyms. What is CS? 1. Computer Science 2. Customer Service 3. Clinical Services 4. Czech 5. Citrate synthase 6. Extension for C# files
  - olup 2y ago
    It's Counter Strike of course
    - vaylian 2y ago
      Common Sense
cjohnson318 2y ago
Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.
- Ufvasl 2y ago
  Docker isn't a project manager, I'm struggling to see the comparison. If you have an app (api/web etc) you would use uv to manage dependencies, lock files and a locam virtual environment for development, and then you could install the same dependencies and the project in a docker image also for deployment.
  - teruakohatu 2y ago
    People certainly use Docker for this purpose. Need a new package? Add a pip install line and rebuild the image. I agree it isn’t the best use of Docker, but with the hell that is conda (and I say this as someone who likes conda more than most other options) and what can feel like insanity managing python environments, Docker isn’t the worst solution. All that said, I moved to uv last year and have been loving it.
    - barosl 2y ago
      Yeah, I also used Docker (actually, Podman) as an alternative Python package manager and it worked well enough. Most of all, it felt somewhat cleaner and more reproducible than using plain virtualenv. Of course, I migrated from it after I learned uv.
- stackskipton 2y ago
  As SRE with a ton of python stuff, nothing has beat Dev Containers with VSCode for not losing my mind with Python. For running containers, pip is best way to go just to keep dependency requirements to minimum.
- raziel2p 2y ago
  even if you go through the hassle of using docker for your local dev environment, you still need something to install dependencies in a reproducible way when you rebuild the image.
IAmNotACellist 2y ago
Is uv better than micromamba? I tried using uv once and got some big ugly error I don't remember, and that was the end of that, whereas mm just worked (perhaps due to my familiarity). It was a project with the usual situation, i.e., torch, numpy, cuda support, nvcc, all had to play nicely together and satisfy requirements.txt.
- simonw 2y ago
  How long ago did you try uv? It just hit its 12 month birthday a few days ago and has evolved a LOT on those past 12 months. One of the problems I ran into with it was patched out within days of me first hitting it. https://simonwillison.net/2024/Nov/8/uv/ https://simonwillison.net/2024/Nov/8/uv/
  - IAmNotACellist 2y ago
    Just a few weeks ago. Sadly I can't remember the specifics but meta-management toolchains are always a hard sell if what you currently have works and is Good Enough. mm is quite fast compared to anaconda, though not perfect. Maybe I'd also benefit from uv having an environment import feature, since I have like 30 *conda environments by now.
- dekhn 2y ago
  I used uv for the first time a few months ago and it was a total revelation (previously I used venv and pip). I would be happy if pip itself and conda went away (although that won't happen).
sieve 2y ago
Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.
- simonw 2y ago
  I don't think pip is to blame for that. PyTorch is sadly an enormous space hog. I just started a fresh virtual environment with "python -m venv venv" - running "du -h" showed it to be 21MB. After running "venv/bin/pip install torch" it's now 431MB. The largest file in there is this one: 178M ./lib/python3.10/site-packages/torch/lib/libtorch_cpu.dylib There's a whole section of the uv manual dedicated just to PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/ https://docs.astral.sh/uv/guides/integration/pytorch/ (I just used find to locate as many libtorch_cpu.dylib files as possible on my laptop and deleted 5.5GB of them)
  - sieve 2y ago
    I use uv pip to install dependencies for any LLM software I run. I am not sure if uv re-implements the pip logic or hands over resolution to pip. But it does not change the fact that I have multiple versions of torch + multiple installations of the same version of torch in the cache. Compare this to the way something like maven/gradle handles this and you have to wonder WTF is going on here.
    - simonw 2y ago
      uv implements its own resolution logic independently of pip. Maybe your various LLM libraries are pinning different versions of Torch? Different Python versions each need their own separate Torch binaries as well. At least with uv you don't end up with separate duplicate copies of PyTorch in each of the virtual environments for each of your different projects!
yair99dd 2y ago
> uv's handling of pre-releases is... unusual. https://github.com/astral-sh/uv/issues/10138 https://github.com/astral-sh/uv/issues/10138
arnath 2y ago
I think the biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible. The ecosystem can be really confusing to approach as an outsider. There’s like 5 different ways to create virtual environments. With uv, you don’t have to care about any of that. The venv and your Python install are just handled for you by ‘uv run’, which is magic.
- myroon5 2y ago
  https://xkcd.com/927/ https://xkcd.com/927/
riskneutral 2y ago
is this better than miniconda?
something98 2y ago
Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add new packages, but rarely update it, unless I feel like a spring cleaning. And I like knowing that I have the same environment across all my machines, so I don’t have to think about if I’m running the same script or notebook on a different machine today. The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow. Addition: I don’t run other’s code, like pretrained models built with specific package requirements.
- ayjay_t 2y ago
  `uv` isn't great for that, I've been specifying and rebuilding my environments for each "project". My one off notebook I'm going to set up to be similar to the scripts, will require some mods. It does take up a lot more space, it is quite a bit faster. However, you could use the workspace concept for this I believe, and have the dependencies for all the projects described in one root folder and then all sub-folders will use the environment. But I mean, our use case is very different than yours, its not necessary to use uv.
  - something98 2y ago
    Gotcha. Thank you. FYI, for anyone else that stumbles upon this: I decided to do a quick check on PyTorch (the most problem-prone dependency I've had), and noticed that they recommending specifically no longer using conda—and have since last November.
- bityard 2y ago
  I personally have a "sandbox" directory that I put one-off and prototype projects in. My rule is that git repos never go in any dir there. I can (and do) go in almost any time and rm anything older than 12 months. In your case, I guess one thing you could do is have one git repo containing you most commonly-used dependencies and put your sub-projects as directories beneath that? Or even keep a branch for each sub-project? One thing about `uv` is that dependency resolution is very fast, so updating your venv to switch between "projects" is probably no big deal.
locusofself 2y ago
I've been mostly out of the python game for quite a while, but I never had that much issue with: pip install -r requirements.txt . Seems like a lot of people have tried their hand at various tooling, so there must be more to it than I am aware of.
- xnyan 2y ago
  Just two reasons (there are more): 1) uv is vastly faster than pip. Just using uv pip install -r requirements.txt and nothing else is a win. 2) uv can handle things like downloading the correct python person, creating a venv (or activating an existing venv if one exists) and essentially all the other cognitive load in a way that's completely transparent to the user. It means you can give someone a Python project and a single command to run it, and you can have confidence it will work on regardless of the platform or a dozen other little variables that trip people up.
  - locusofself 2y ago
    I'll give it a whirl soon
- svachalek 2y ago
  This works if you only have one python project on your system, but most python developers need virtual environments to deal with various projects.
  - locusofself 2y ago
    sure, even so I think I had like one or two bash aliases to create/switch virtualenvs
  - thisgoodlife 2y ago
    I create a .venv directory for each project(even for those test projects named pytest, djangotest). And each project has its own requirements file. Personally, Python packaging has never been a problem.
barosl 2y ago
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'] # /// import requests from bs4 import BeautifulSoup After being used to this workflow, I have been thinking that a dedicated syntax for inline dependencies would be great, similar to JavaScript's `import ObjectName from 'module-name';` syntax. Python promoted type hints from comment-based to syntax-based, so a similar approach seems feasible. > It used to be that either you avoided dependencies in small Python script, or you had some cumbersome workaround to make them work for you. Personally, I used to manage a gigantic venv just for my local scripts, which I had to kill and clean every year. I had the same fear for adding dependencies, and did exactly the same thing. > This is the kind of thing that changes completely how you work. I used to have one big test venv that I destroyed regularly. I used to avoid testing some stuff because it would be too cumbersome. I used to avoid some tooling or pay the price for using them because they were so big or not useful enough to justify the setup. And so on, and so on. I 100% sympathize with this.
- shlomo_z 2y ago
  This is a nice feature, but I've not found it to be useful, because my IDE wont recognize these dependencies. Or is it a skill issue?
  - EdwardDiego 2y ago
    No, it's the fact that it's a rather new PEP, and our IDEs don't yet support it, because, rather new.
  - zahlman 2y ago
    What exactly do you imagine that such "recognition" would entail? Are you expecting the IDE to provide its own package manager, for example?
BeetleB 2y ago
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".
- claytonjy 2y ago
  It does replace pipenv. They might not mention it because it's not widely used these days; most pipenv users switched to poetry sometime over the last half-decade or so. There is a request for `uv shell` or similar[0], but it's trickier than it looks, and even poetry gave up `poetry shell` in their recent 2.0 release. [0]: https://github.com/astral-sh/uv/issues/1910 https://github.com/astral-sh/uv/issues/1910
- skeledrew 2y ago
  I use autoenv, which runs a .env file when switching to a folder with it, and of course it has an activation command.
- krupan 2y ago
  Use direnv for automatically creating, activating, and deactivating your virtual environments. I don't know how anyone lives any other way. Just put this in a .envrc file (substituting whichever python version you are using): layout python python3.12 pip install --upgrade pip python -m pip install -r requirements.txt Looks like direnv can be extended to use uv: https://github.com/direnv/direnv/wiki/Python#uv https://github.com/direnv/direnv/wiki/Python#uv
- BiteCode_dev 2y ago
  You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.
  - selectnull 2y ago
    While working in Django projects, one would prefer to have an environment activarted to perform all kinds of django-admin commands, I certainly wouldn't want to do via `uv run`. Also, `nvim` is started with an environment activated if you want all the LSP goodies. `uv run` is good for some things, but I prefer to have my venv activated as well.
deleted 2y ago
[deleted]
k2enemy 2y ago
uv is just so damn good. All else equal, I prefer julia to python, but uv makes the python experience so much nicer. I'd love it if julia copied uv and replaced the Pkg system with it.
- sidpatil 2y ago
  What are some of the issues you've had with the Pkg system?
claytonjy 2y ago
A scenario for "don't use uv" I hope none of you encounter: many nvidia libraries not packaged up in something better like torch. Here's just one example, nemo2riva, the first in several steps to taking a trained NeMo model and making it deployable: https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#export-nemo-models-to-riva-with-nemo2riva https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#... before you can install the package, you first have to install some other package whose only purpose is to break pip so it uses nvidia's package registry. This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit. This is of course not Astral's fault, I don't expect them to handle this, but uv has spoiled me so much it makes anything else even more painful than it was before uv.
- ziml77 2y ago
  Surely you can just manually add their index, right?
  - zahlman 2y ago
    Yes, but the point is that they automate the process for you, because it's finicky.
  - claytonjy 2y ago
    yes, but if you’re not in their carefully directed “nemo environment” the nemo2riva command fails complaining about some hydra dependency. and on it goes…
- lijok 2y ago
  Instead of installing nvidia-pyindex, use https://docs.astral.sh/uv/configuration/indexes/ https://docs.astral.sh/uv/configuration/indexes/ to configure the index nvidia-pyindex points to.
- zahlman 2y ago
  >whose only purpose is to break pip so it uses nvidia's package registry. This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit. I guess you're really talking about `nvidia-pyindex`. This works by leveraging the legacy Setuptools build system to "build from source" on the user's machine, but really just running arbitrary code. From what I can tell, it could be made to work just as well with any build system that supports actually orchestrating the build (i.e., not Flit, which is designed for pure Python projects), and with the modern `pyproject.toml` based standards. It's not that it "doesn't work with uv"; it works specifically with Pip, by trying to run the current (i.e.: target for installation) Python environment's copy of Pip, calling undocumented internal APIs (`from pip._internal.configuration import get_configuration_files`) to locate Pip's config, and then parsing and editing those files. If it doesn't work with `uv pip`, I'm assuming that's because uv is using a vendored Pip that isn't in that environment and thus can't be run that way. Nothing prevents you, incidentally, from setting up a global Pip that's separate from all your venvs, and manually creating venvs that don't contain Pip (which makes that creation much faster): https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... But it does, presumably, interfere with hacks like this one. Pip doesn't expose a programmatic API, and there's no reason why it should be in the environment if you haven't explicitly declared it as a dependency - people just assume it will be there, because "the user installed my code and presumably that was done using Pip, so of course it's in the environment".
d3v1an7 2y ago
great write up! have only dabbled in python, but dabbled enough to understand and _feel_ each dotpoint under "what problems uv tries to solve".
digdugdirk 2y ago
I'm very much looking forward to their upcoming static type checker. Hopefully it will lead to some interesting new opportunities in the python world!
MassPikeMike 2y ago
I have seen references to using uv for Python package management before and been thoroughly confused. I never realized it was not the same thing as the very nice asynchronous cross-platform library libuv (https://libuv.org/ https://libuv.org/) and I could never figure out what that library had to do with Python package management (answer: nothing). Maybe we need a Geographic Names Board to deconflict open source project names, or at least the ones that are only two or three characters long.
iandanforth 2y ago
Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable. You don't have to love uv, and there are plenty of reasons not to.
- data_ders 2y ago
  conda user for 10 years and uv skeptic for 18 months. I get it! I loved my long-lived curated conda envs. I finally tried uv to manage an environment and it’s got me hooked. That a projects dependencies can be so declarative and separated from the venv really sings for me! No more meticulous tracking of a env.yml or requirements.txt just ‘uv add` and `uv sync` and that’s it! I just don’t think about it anymore
  - synparb 2y ago
    I'm also a long time conda user and have recently switched to pixi (https://pixi.sh/ https://pixi.sh/), which gives a very similar experience for conda packages (and uses uv under the hood if you want to mix dependencies from pypi). It's been great and also has a `pixi global` similar to `pipx`, etc the makes it easy to grab general tools like ripgrep, ruff etc and make them widely available, but still managed.
    - data_ders 2y ago
      whoa! TIL thanks will check it out
- falcor84 2y ago
  > I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable. TFA offers a myriad innovative and pleasing examples. It would have been nice if you actually commented on any of those, or otherwise explained why you think otherwise.
triyambakam 2y ago
I didn't find any mention comparing it to rye. Anyone have any insight? I am pretty distant from the day to day Python ecosystem lately
- LordKeren 2y ago
  The astral team, creators of uv, have also subsumed rye So it’ll get rolled into UV
- ilyagr 2y ago
  Rye is softly being sunset in favor of `uv` (though still officially supported, and I haven't heard of any plans to change that). As it says on https://rye.astral.sh/ https://rye.astral.sh/, > If you're getting started with Rye, consider uv, the successor project from the same maintainers. > While Rye is actively maintained, uv offers a more stable and feature-complete experience, and is the recommended choice for new projects. It also links to https://github.com/astral-sh/rye/discussions/1342 https://github.com/astral-sh/rye/discussions/1342.
jquaint 2y ago
I excited to try uv for my next project. It seems like a good future proof way to package python packages in Nix. https://github.com/pyproject-nix/uv2nix https://github.com/pyproject-nix/uv2nix
emseetech 2y ago
I can't speak to uv from an app dev perspective (I use Go for that), but as someone who dips into the Python world for data science reasons only, uv is great and I'm thankful for it.
ijustlovemath 2y ago
How are they handling the returns VCs expect through this free software? If it's so easy to deploy, surely we should expect a Docker-like licensing model in the near future?
ashishb 2y ago
Has someone migrated from poetry to uv? Any benefits?
- JodieBenitez 2y ago
  Yes. The main benefits for me and my coworkers are speed and automatic fetching of Python interpreter. It's so fast that it's a pleasure to use (same thing could be said about ruff vs. black). And the fact that it downloads the right Python interpreter specified in the project's pyproject.toml means my coworker don't have to care about installing and managing Python versions. They don't even need to have a Python installed in the first place. Otherwise, it works pretty much like Poetry. Unfortunately Poetry is not standards-compliant with the pyproject.toml, so you'll have to rewrite it. There are tools for this, never bothered with them though.
- BiteCode_dev 2y ago
  Mostly less modes of failures, particularly at bootstrapping.
- dagw 2y ago
  In addition to all the benefits others have mentioned, biggest benefit for me was that with uv you can easily bring your own build system (scikit-build-core in my case). Poetry comes with its own build system that didn't work for my needs and working around that was a massive pain and quite fragile. With uv I can use the build system that works best for me. On the whole uv is less opinionated than poetry. By default it will do sensible things, but if that thing doesn't work in your particular weird case, it is much easier to make uv work for you than poetry. Poetry gets very angry if you try to hold it wrong.
lysecret 2y ago
Really like uv too but surprised he doesn’t mention the lack of conda compliance. Some scientific packages only being available on conda is the only reason I can’t use uv (but micromamba) for some projects.
- BiteCode_dev 2y ago
  conda compiance is nearly impossible to get because the typical anaconda project doesn't exist: it's a separate ecosystem with huge variability that is by design incompatible with everything else and that no two teams use in the same way.
__rito__ 2y ago
Is there a conda to uv migration tutorial written by anyone? I have installed miniconda system-wide. For any Python package that I use a lot, I install them on base environment. And on other environments. Like ipython. For every new project, I create a conda environment, and install everything in it. Upon finishing/writing my patch, I remove that environment and clean the caches. For my own projects, I create an environment.yaml and move on. Everything works just fine. Now, the solving with mamba is fast. I can just hand someone the code and environment.yaml, and it runs on other platforms. Can someone say why using uv is a good idea? Has anyone written a migration guide for such use cases? I am mightily impressed by one line dependency declaration in a file. But I don't know (yet) where the caches are stored, how to get rid of them later, etc.
BrenBarn 2y ago
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 conda doesn't seem to have which uv has is all the "project management" stuff. Which is fine, it's clear people want that. But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.) The pro and con of tools like uv is that they layer over the base-level tools like pip. The pro of that is that they interoperate well with pip. The con is that they inherit the limitations of that packaging model (notably the inability to distribute non-Python dependencies separately). That's not to say uv is bad. It seems like a cool tool and I'm intrigued to see where it goes.
- necessary 2y ago
  The killer feature of uv for me is much faster uv pip install -r requirements.txt.
- agent281 2y ago
  > But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.) I used conda for awhile around 2018. My environment became borked multiple times and I eventually gave up on it. After that, I never had issues with my environment becoming corrupted. I knew several other people who had the same issues and it stopped after they switched away from conda. I've heard it's better now, but that experience burned me so I haven't kept up with it.
- uneekname 2y ago
  Yes, conda has a lot more features on paper. And it supports non-Python dependencies which is super important in some contexts. However, after using conda for over three years I can confidently say I don't like using it. I find it to be slow and annoying, often creating more problems than it solves. Mamba is markedly better but still manages to confuse itself. uv just works, if your desktop environment is relatively modern. that's its biggest selling point, and why I'm hooked on it.
upbeat_general 2y ago
I tried out uv a bit ago and dropped it. But about two weeks ago, I switched to it and migrated two projects with no issues. Things like pypi sources per dep are there finally. I still find rough points (as many others pointed out, especially with non sandboxed installs), that are problematic, but on the whole it’s better than Mamba for my use.
motorest 2y ago
I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/ https://libuv.org/
- inejge 2y ago
  I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. (The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)
  - sph 2y ago
    Sure, there are so few backend Node.js engineers. Let alone game engine developers and Blender users with their UV mapping tools. None of these people will ever encounter Python in their daily lives.
    - wiseowise 2y ago
      [flagged]
      - hu3 2y ago
        That's unnecessarily rude.
  - nonameiguess 2y ago
    I'm not sure that's true. uvloop, built on libuv, is a pretty popular alternative event loop for async Python, much faster than the built-in. It certainly confused me at first to see a tool called "uv" that had nothing to do with that, because I'd been using libuv with Python for years before it came out.
  - motorest 2y ago
    > I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. Google returns mixed results. You may assert it's not problematic, but this is a source of noise that projects with distinct names don't have.
tiltowait 2y ago
The challenge I have with adopting uv is it feels like it doesn't have a great replacement for poetry's `[tool.poetry.scripts]` block. For instance, from a personal project that uses a src layout, without being a package, I have this in my pyproject.toml: [tool.poetry] ... packages = [{ include = "*", from = "src", format = "sdist" }] ... [tool.poetry.scripts] botch = "launcher:run_bot('botch')" beat = "launcher:run_bot('beat')" I can't find any way to get that working in uv without some pretty major refactoring of my internal structure and import declarations. Maybe I've accidentally cornered myself in a terrible and ill-advised structure?
- simonw 2y ago
  It looks like uv will get script support eventually: https://github.com/astral-sh/uv/issues/5903 https://github.com/astral-sh/uv/issues/5903
- semi-extrinsic 2y ago
  You can do this: [project.scripts] hello = "example:hello" Assuming you have src/example.py with a function called hello, then "uv run hello" will call that function. I think you also need to have a (empty) src/__init__.py file.
- zahlman 2y ago
  [project.scripts] is the PEP621 equivalent, supported by multiple backends including vanilla Setuptools. (When you use [tool.poetry.scripts], it's really the build backend, Masonry, that cares.) So that's the uv way, too. Or the "bear skins and stone knives" way. I don't know what you mean by "without being a package". I guess you mean that Poetry will also run your code without installing it anywhere, and use the marked entry points directly. Per the other replies, apparently uv will get an equivalent soon. But really, the point of having `pyproject.toml` in the first place is to explain how to build an installable wheel and/or sdist for your project, and you basically get it for free. (Even if you don't include a [build-system] table, the standards say to use Setuptools by default anyway.) (Of course, uv can already `run` your entry point, but this involves installing the code in a temporary venv.) > without some pretty major refactoring of my internal structure and import declarations. Maybe I've accidentally cornered myself in a terrible and ill-advised structure? Possibly. Is the code up on GitHub? I could take a look.
microflash 2y ago
uv has been fantastic for most of my personal projects. It feels so much smoother than any other python tooling combo I tried in past. That said, it just does not work well behind corporate proxies. This is single most annoying thing that has stopped me from recommending it at work.
speakspokespok 2y ago
Has anyone built pipy packages with `uv`? Does doing so affect the end-user at all?
- simonw 2y ago
  What do you mean by building a pipy package? If you mean creating and publishing packages to PyPI end users can't tell if you used uv or poetry or something else.
- trallnag 2y ago
  Works fine. But for people on Github for now I recommend using uv only for building distributions and using the official PyPA GitHub action for publishing them to PyPI. This way you can take advantage of attestation, something not yet supported by uv.
datadeft 2y ago
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.
- gyomu 2y ago
  What’s a good flask (+jinja) equivalent for rust?
  - selectnull 2y ago
    Actix + minijinja Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.
  - datadeft 2y ago
    I use Axum and Askama for such usecases.
- wiseowise 2y ago
  Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?
  - datadeft 2y ago
    Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.
    - lmm 2y ago
      You can get pretty far without needing to run pip. Whereas you can't change anything in a rust codebase without compiling it.
- procaryote 2y ago
shlomo_z 2y ago
A familiar tale: Joe is hesitant about switching to UV and isn't particularly excited about it. Eventually, he gives it a try and becomes a fan. Soon, Joe is recommending UV to everyone he knows.
- EdwardDiego 2y ago
  Joe has found the One True God, Joe must proselytise, the true God demands it.
mherrmann 2y ago
> There are a lot of different ways to install Python, all with different default settings, and gotchas. With uv, there is now one more. https://xkcd.com/927/ https://xkcd.com/927/
- vaylian 2y ago
  Arnim Ronacher, author of rye (later uv) has very clearly highlighted that exact xkcd when he started working on rye. But he still decided that it was worth a try and as it turns out, rye/uv has become something that has a realistic chance of becoming the way to use python for most use-cases.
  - mherrmann 2y ago
    Cool point, thank you. I think his name is Armin.
    - vaylian 2y ago
      Thanks. You are right. Unfortunately I can't edit my post any longer.
egorfine 2y ago
Can anyone explain to a non-python developer why python infrastructure is so much broken around the version management? It looks to me that every new minor python release is a separate additional install because realistically you cannot replace python 3.11 with python 3.12 and expect things to work. How did they put themselves in such a mess?
- cpburns2009 2y ago
  Python code rarely breaks between minor version releases in my experience. Python 3.5 introduced the `async` keyword (PEP 492), and Python 3.7 changed `StopIteration` handling in generators (PEP 479).
davedx 2y ago
Astral is doing phenomenal work. I'm extremely excited about the ruff type checker too.
DoingIsLearning 2y ago
As a dabbler (using python mostly for internal engineering tools and post processing of data) I am using uv at home but not in a professional setting. The latest release is at 0.6.1, what is missing (roadmap/timeline wise) for uv to exist as a 1.0 release?
meindnoch 2y ago
Ok, so apparently `uv` has nothing to do with `libuv`.
BiteCode_dev 2y ago
Author here. A.m.a
- tartieret 2y ago
  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!)
  - BiteCode_dev 2y ago
    uv export?
antirez 2y ago
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.
- nickelpro 2y ago
  This is not packaging hell, this is you having a personal problem with how other developers work. Python has come an immensely long way in the world of packaging, the modern era of PEP 517/518 and the tooling that has come along with it is a game changer. There are very few language communities as old as Python with packaging ecosystems this healthy. I've had conversations with members of SG15, the C++ tooling subgroup, where Python's packaging ecosystem and interfaces are looked on enviously as systems to steal ideas from.
gkfasdfasdf 2y ago
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?
- roland35 2y ago
  You probably need to make sure you have the correct python version set. By default it is in the .venv directory with uv
- _whiteCaps_ 2y ago
  I start a shell with "uv run bash" and start neovim from there. I'm sure there's other ways but it's a quick fix and doesn't involve mucking around with neovim config.
  - gkfasdfasdf 2y ago
    That's brilliant, thanks! EDIT - 'uv run nvim' works also
torcete 2y ago
uv, venv, conda, brew, deb, nix, guix, chocolatey, containers, jails... One day we will finally find the ONE solution to this problem.
- greenie_beans 2y ago
  call it: one
evanwpm 2y ago
uv has been a complete game changer for me in Python, everyone who develops with me knows I won't shut up about it. Astral is a great team, they built the ruff linter and are currently working on a static type checker called red-knot: https://x.com/charliermarsh/status/1884651482009477368 https://x.com/charliermarsh/status/1884651482009477368
nchmy 2y ago
Just going to plug https://mise.jdx.dev https://mise.jdx.dev as a perfect accompaniment to uv. It simplifies installing tooling across languages and projects. I even install uv via mise, and it uses uv under the hood for Python related things.
perrygeo 2y ago
> You don't even need to know there is a venv, or what activation means. > All those commands update the lock file automatically and transparently.... It's all taken care of. When is the python community going to realize that simple is the opposite of easy? I don't see how hiding these aspects is desirable at all; I want to know how my programming tools work! With all due respect to the author, I don't like the assumption that all programmers want magic tools that hide everything under the rug. Some programmers still prefer simplicity, ie understanding exactly what every part of the system does. Nothing against uv, it seems like a fine tool. And I'm sure one could make a case for it on other technical merits. But choosing it specifically to avoid critical thinking is self-defeating.
- ijustlovemath 2y ago
  I think that when you, as most HN commenters are wont to do, are trying to achieve a certain level of mastery in your craft, you're going to want to dive deep, understand the abstractions, have full control, be able to start with nothing but a UDP socket and a steady hand, but that approach misses a huge number of users of these languages. You don't want scientists to have to worry about setting up a venv, you want them to analyze their data and move on with their lives. Sure, people like you or me will be able to setup and source a venv in no time, without expending much mental energy, but we're not who this product is for. It's for the rest of the users, the 99% who aren't even aware places like this exist. All that said, I'm pretty skeptical of using uv until their monetization strategy is clear. The current setup is making me think we're in for a Docker-like license change.
- 392 2y ago
  There is simplicity of interface and then of implementation. If you try uv you will find it is both convenient and easier to understand than competing solutions, because everything _just works_ and you find the proof of how it works waiting in your `git status`. You can be assisted in knowing that it just works because its install takes no time and no system setup. It is slick.
- zahlman 2y ago
  A recurring theme I've seen in Python packaging community discussion is that a lot of people really seem to hate venvs, mostly for reasons I consider quite irrational. And if they don't outright hate the things, they fear having to try to explain them to newbies. Keep in mind: there are huge numbers of people out there who will cargo-cult about how applying the sudo hammer to Pip fixed something or other (generally, because the root user has different environment variables). People even resent having to do user-level installations; they resent venvs even more. When the Python team collaborated with multiple Linux distros to add a system to protect against global user-level installs (because they were still interfering with system Python tools), a lot of people reacted by doing whatever they could to circumvent that protection, and advising each other on how to do so - thus the education effort described in https://discuss.python.org/t/the-most-popular-advice-on-the-internet-for-error-externally-managed-environment-is-to-force-packages-to-be-system-installed/56900 https://discuss.python.org/t/the-most-popular-advice-on-the-... . People really would, apparently, rather add `--break-system-packages` to a command line so that they can keep installing everything in the same place, than attempt to understand even the basics of environment management. And we're talking about programmers here, mind. And then there are the complaints about how the __pypackages__ proposal (https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/) failed - e.g. https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/#pep-582-the-future-of-python-packaging https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth... . There were serious issues with that idea, which only became clear as the discussion dragged on and on across literally years (https://discuss.python.org/t/pep-582-python-local-packages-directory/963 https://discuss.python.org/t/pep-582-python-local-packages-d...). But people were quite upset about having to stick with the old venv model - including the guy who wrote the best explanation of venvs I know, which I frequently refer beginners to (https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi...). A lot of programmers seem to love having the details not only hidden, but as inaccessible as possible, as long as the UI is nice enough. (Unless we're talking about their own code. Then, hundred-line functions are just hunky-dory.)
deleted 2y ago
[deleted]
remram 2y ago
The problem I have with uv is that it is not opinionated enough, or complete enough. It still needs a backend for building the package, and you still have a choice of backends. In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how to do x/y/z. You'll still have to switch from hatchling to flit/pdm/setuptools/... if you run into a limitation of hatchling. As a package author, you're never using uv, you're using uv+hatchling (or uv+something) and a big part of your pyproject.toml are not uv's configuration, it is hatchling configuration. I'm sticking with Poetry for now, which has a more streamlined workflow. Things work together. Every Poetry project uses the same configuration syntax (there are no Poetry+X and Poetry+Y projects). Issues in Poetry can be fixed by Poetry rather than having to work with the backend. I understand that uv is still young and I am sure this will improve. Maybe they'll even pick a specific backend and put a halt to this. But of course Poetry might catch up before then.
- ofek 2y ago
  Hatchling maintainer here :) What limitations have you personally experienced?
- tmvphil 2y ago
  They are currently in the process of creating their own build system: https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266 https://github.com/astral-sh/uv/issues/3957#issuecomment-265...
- zahlman 2y ago
  >In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how to do x/y/z. You'll still have to switch from hatchling to flit/pdm/setuptools/... if you run into a limitation of hatchling. As a package author, you're never using uv, you're using uv+hatchling (or uv+something) and a big part of your pyproject.toml are not uv's configuration, it is hatchling configuration. Strange. The main reason I'm not using uv or its competitors (or going back to Poetry, where I was using only a tiny fraction of the functionality) is that they're all too opinionated and all-in-one for me. If I had to write down a top 10 of reasons the Python packaging ecosystem is a "mess", and give detailed reasoning, probably at least 6 of them would be problems with Pip specifically (including things that appear to be problems in other tools, but which are really Pip's fault). And at least one more would be "Setuptools is a massive pile of backwards-compatibility wrappers that are mostly useless with the modern packaging flow, that didn't even directly make the wheels (relying on a separate dependency instead) until 70.1". (The other reason I wouldn't go back to Poetry is because Masonry was a terrible, non-standards-compliant experience for me, and its installation procedures changed repeatedly over time, and you'd end up not being able to uninstall old versions cleanly.) (Hatchling and Setuptools are build backends, yes; where you say "flit" I assume you mean flit-core, and similarly pdm-backend for PDM.) If uv provided its own backend, there would still be a risk of running into limitations with that backend; and regardless you'd have to go through its docs to figure out how to do x/y/z with it. Being able to experiment with different build backends was part of the explicit rationale for `pyproject.toml` in the first place. The authors of PEP 517 and 518 consciously expected to see competing backends pop up (and explicitly designed a system that would allow that competition, and allow for Pip etc. to know how to invoke every backend), and did not (per my understanding of Python Discourse forum discussion) consciously expect to see competing workflow tools pop up. I'm making a build backend because I have my own opinion. I don't have any interest in making a workflow tool. I want people who like uv to be able to use my build backend. That's how the system was designed to work. I don't want someone to integrate the baseline and make all the decisions for me. I want a better-quality baseline. Which is why I'm also making an installer/environment manager. `build` is a perfectly fine build frontend. I don't need or want a replacement.
zellyn 2y ago
I've been using Hermit to install uv, then pointing scripts at $REPO_ROOT/bin/uv. That gives you a repo where the scripts can be run directly after cloning (Hermit is smart enough to install itself if necessary). Unfortunately, Hermit doesn't do Windows, although I'm pretty sure that's because the devs don't have Windows machines: PRs welcome. https://github.com/cashapp/hermit https://github.com/cashapp/hermit
mathisd 2y ago
I really like uv and I have successfully got rid of miniconda but : - I wish there was a global virtual environment which could be referenced and activated from terminal. Not every new scripts needs their own .venv in their respective folder. uv takes the route of being project centered and based on file system, this works for me most of the time but sometime it doesn't. - I wish we could avoid the .python_version file and bundle it in the pyproject.toml file.
- auxym 2y ago
  Agreed, I like to have a "general use" environment to use for various one-off interactive python sessions, scripts or jupyter notebooks.

723 points by bertdb 2y ago

Yes. Python tooling has been shit for decades and `uv` is actually good.

Adding to the article (which I agree with): Lack of `uv pip install --user` has made transitioning our existing python environment a bit more challenging than I'd like, but not a deal breaker.

edudobay 2y ago
Out of curiosity, how does `--user` fall in your use case? It got me confused because this flag makes it install to a central location within the user home directory and not to a virtual environment.

pityJuke 2y ago

uv is overposted as hell, but oh my god I love it so much I understand every single one of these posts. Simple things just work so effectively.

serjester 2y ago

I think at this point, the only question it remains is how Astral will make money. But if they can package some sort enterprise package index with some security bells and whistles it seems an easy sell into a ton of orgs.

BiteCode_dev 2y ago
Charlie Marsh said in our interview they plan to compete with anaconda on b2b: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-the https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th... Make sense, the market is wide open for it.

NeutralForest 2y ago

uv is so much better than everything else, I'm just can't afraid they can't keep the team going. Time will tell but I just use uv and ruff in every project now tbh.

kyawzazaw 2y ago
really need them to keep going the amount of people who switch to R because Python is too hard to setup is crazy high. Especially among the life scientists and statisticians

belval 2y ago

> I had a friend who decided to not use uv, because the first time he used it, it was on a 15 years old codebase that had just been migrated to Python 3. It was standing on a pile of never cleaned up pip freeze exports, and uv could not make it work. This is my only gripe with uv, despite how the author decided to depict it, this really turns into a headache fast as soon as you have ~4-5 in-house packages. I don't think it's that bad that uv is so unforgiving in those case because it leads to better overall project quality/cohesion, but I wish there was a way to more progressively onboard and downgrade minor version mismatch to warnings.

code_biologist 2y ago
Did they run into a hard blocker, or was it just that using version overrides was possible but painful? I started looking seriously at uv/pdm once poetry made it entirely clear they didn't intend to support version overrides [1]. uv's support for overrides seems serviceable if unsophisticated [2][3]. [1] https://github.com/python-poetry/poetry/issues/697 https://github.com/python-poetry/poetry/issues/697 [2] https://docs.astral.sh/uv/concepts/resolution/#dependency-overrides https://docs.astral.sh/uv/concepts/resolution/#dependency-ov... [3] https://docs.astral.sh/uv/reference/settings/#override-dependencies https://docs.astral.sh/uv/reference/settings/#override-depen...
- aaravchen 2y ago
  The linked poetry Issue is pretty understandable why they aren't going to support it. I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency. Point blank, that's a packaging failure and the solution is, and always has been, to immediately yank the offending package. That said, the Python case has pretty limited ability to specify dependency package versions, which makes it nigh impossible to handle it downstream by blocklisting specific versions from an otherwise contiguous range. Take for example the werkzeug package that released a breaking API regression in a patch release version. It didn't affect everyone, but notably did affect certain Flask(?) use cases that used werkzeug as a dependency. In a sane system, either werkzeug immediately removes the last released version as buggy (and optionally re-releases it as a non-backwards compatible SemVer change), or everyone starts looks for an alternative to non-compliant werkzeug. Pragmatically though, Python dependency specification syntax should have a way for Flask to specify, in a patch release of its own, that werkzeug up to the next minor version, _but excluding a specific range of patch versions_, is a dependency. Allowing them to monkey patch the problem in the short term. It should never be on the end user to be specifying overrides of indirect dependency specifications at the top level though, which is what was requested from the poetry tool.

3l3ktr4 2y ago

I thought this was going to be about the UV rays from the sun... But it's another python package manager. We're running out of names.

teraflop 2y ago
I assumed it was going to be about libuv, the event loop library that Node uses.
__MatrixMan__ 2y ago
Were you considering migrating to ultraviolet light? Vitamin D is indeed important, but that mutagenesis is no joke. I'd suggest against it.
- userbinator 2y ago
  I read it as "should you migrate to a more or less sunny region".
paulddraper 2y ago
I think you mean running out of acronyms. What is CS? 1. Computer Science 2. Customer Service 3. Clinical Services 4. Czech 5. Citrate synthase 6. Extension for C# files
- olup 2y ago
  It's Counter Strike of course
  - vaylian 2y ago
    Common Sense

cjohnson318 2y ago

Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.

Ufvasl 2y ago
Docker isn't a project manager, I'm struggling to see the comparison. If you have an app (api/web etc) you would use uv to manage dependencies, lock files and a locam virtual environment for development, and then you could install the same dependencies and the project in a docker image also for deployment.
- teruakohatu 2y ago
  People certainly use Docker for this purpose. Need a new package? Add a pip install line and rebuild the image. I agree it isn’t the best use of Docker, but with the hell that is conda (and I say this as someone who likes conda more than most other options) and what can feel like insanity managing python environments, Docker isn’t the worst solution. All that said, I moved to uv last year and have been loving it.
  - barosl 2y ago
    Yeah, I also used Docker (actually, Podman) as an alternative Python package manager and it worked well enough. Most of all, it felt somewhat cleaner and more reproducible than using plain virtualenv. Of course, I migrated from it after I learned uv.
stackskipton 2y ago
As SRE with a ton of python stuff, nothing has beat Dev Containers with VSCode for not losing my mind with Python. For running containers, pip is best way to go just to keep dependency requirements to minimum.
raziel2p 2y ago
even if you go through the hassle of using docker for your local dev environment, you still need something to install dependencies in a reproducible way when you rebuild the image.

IAmNotACellist 2y ago

Is uv better than micromamba? I tried using uv once and got some big ugly error I don't remember, and that was the end of that, whereas mm just worked (perhaps due to my familiarity). It was a project with the usual situation, i.e., torch, numpy, cuda support, nvcc, all had to play nicely together and satisfy requirements.txt.

simonw 2y ago
How long ago did you try uv? It just hit its 12 month birthday a few days ago and has evolved a LOT on those past 12 months. One of the problems I ran into with it was patched out within days of me first hitting it. https://simonwillison.net/2024/Nov/8/uv/ https://simonwillison.net/2024/Nov/8/uv/
- IAmNotACellist 2y ago
  Just a few weeks ago. Sadly I can't remember the specifics but meta-management toolchains are always a hard sell if what you currently have works and is Good Enough. mm is quite fast compared to anaconda, though not perfect. Maybe I'd also benefit from uv having an environment import feature, since I have like 30 *conda environments by now.
dekhn 2y ago
I used uv for the first time a few months ago and it was a total revelation (previously I used venv and pip). I would be happy if pip itself and conda went away (although that won't happen).

sieve 2y ago

Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.

simonw 2y ago
I don't think pip is to blame for that. PyTorch is sadly an enormous space hog. I just started a fresh virtual environment with "python -m venv venv" - running "du -h" showed it to be 21MB. After running "venv/bin/pip install torch" it's now 431MB. The largest file in there is this one: 178M ./lib/python3.10/site-packages/torch/lib/libtorch_cpu.dylib There's a whole section of the uv manual dedicated just to PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/ https://docs.astral.sh/uv/guides/integration/pytorch/ (I just used find to locate as many libtorch_cpu.dylib files as possible on my laptop and deleted 5.5GB of them)
- sieve 2y ago
  I use uv pip to install dependencies for any LLM software I run. I am not sure if uv re-implements the pip logic or hands over resolution to pip. But it does not change the fact that I have multiple versions of torch + multiple installations of the same version of torch in the cache. Compare this to the way something like maven/gradle handles this and you have to wonder WTF is going on here.
  - simonw 2y ago
    uv implements its own resolution logic independently of pip. Maybe your various LLM libraries are pinning different versions of Torch? Different Python versions each need their own separate Torch binaries as well. At least with uv you don't end up with separate duplicate copies of PyTorch in each of the virtual environments for each of your different projects!

yair99dd 2y ago

> uv's handling of pre-releases is... unusual. https://github.com/astral-sh/uv/issues/10138 https://github.com/astral-sh/uv/issues/10138

arnath 2y ago

I think the biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible. The ecosystem can be really confusing to approach as an outsider. There’s like 5 different ways to create virtual environments. With uv, you don’t have to care about any of that. The venv and your Python install are just handled for you by ‘uv run’, which is magic.

myroon5 2y ago
https://xkcd.com/927/ https://xkcd.com/927/

riskneutral 2y ago

is this better than miniconda?

something98 2y ago

Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add new packages, but rarely update it, unless I feel like a spring cleaning. And I like knowing that I have the same environment across all my machines, so I don’t have to think about if I’m running the same script or notebook on a different machine today. The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow. Addition: I don’t run other’s code, like pretrained models built with specific package requirements.

ayjay_t 2y ago
`uv` isn't great for that, I've been specifying and rebuilding my environments for each "project". My one off notebook I'm going to set up to be similar to the scripts, will require some mods. It does take up a lot more space, it is quite a bit faster. However, you could use the workspace concept for this I believe, and have the dependencies for all the projects described in one root folder and then all sub-folders will use the environment. But I mean, our use case is very different than yours, its not necessary to use uv.
- something98 2y ago
  Gotcha. Thank you. FYI, for anyone else that stumbles upon this: I decided to do a quick check on PyTorch (the most problem-prone dependency I've had), and noticed that they recommending specifically no longer using conda—and have since last November.
bityard 2y ago
I personally have a "sandbox" directory that I put one-off and prototype projects in. My rule is that git repos never go in any dir there. I can (and do) go in almost any time and rm anything older than 12 months. In your case, I guess one thing you could do is have one git repo containing you most commonly-used dependencies and put your sub-projects as directories beneath that? Or even keep a branch for each sub-project? One thing about `uv` is that dependency resolution is very fast, so updating your venv to switch between "projects" is probably no big deal.

locusofself 2y ago

I've been mostly out of the python game for quite a while, but I never had that much issue with: pip install -r requirements.txt . Seems like a lot of people have tried their hand at various tooling, so there must be more to it than I am aware of.

xnyan 2y ago
Just two reasons (there are more): 1) uv is vastly faster than pip. Just using uv pip install -r requirements.txt and nothing else is a win. 2) uv can handle things like downloading the correct python person, creating a venv (or activating an existing venv if one exists) and essentially all the other cognitive load in a way that's completely transparent to the user. It means you can give someone a Python project and a single command to run it, and you can have confidence it will work on regardless of the platform or a dozen other little variables that trip people up.
- locusofself 2y ago
  I'll give it a whirl soon
svachalek 2y ago
This works if you only have one python project on your system, but most python developers need virtual environments to deal with various projects.
- locusofself 2y ago
  sure, even so I think I had like one or two bash aliases to create/switch virtualenvs
- thisgoodlife 2y ago
  I create a .venv directory for each project(even for those test projects named pytest, djangotest). And each project has its own requirements file. Personally, Python packaging has never been a problem.

barosl 2y ago

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'] # /// import requests from bs4 import BeautifulSoup After being used to this workflow, I have been thinking that a dedicated syntax for inline dependencies would be great, similar to JavaScript's `import ObjectName from 'module-name';` syntax. Python promoted type hints from comment-based to syntax-based, so a similar approach seems feasible. > It used to be that either you avoided dependencies in small Python script, or you had some cumbersome workaround to make them work for you. Personally, I used to manage a gigantic venv just for my local scripts, which I had to kill and clean every year. I had the same fear for adding dependencies, and did exactly the same thing. > This is the kind of thing that changes completely how you work. I used to have one big test venv that I destroyed regularly. I used to avoid testing some stuff because it would be too cumbersome. I used to avoid some tooling or pay the price for using them because they were so big or not useful enough to justify the setup. And so on, and so on. I 100% sympathize with this.

shlomo_z 2y ago
This is a nice feature, but I've not found it to be useful, because my IDE wont recognize these dependencies. Or is it a skill issue?
- EdwardDiego 2y ago
  No, it's the fact that it's a rather new PEP, and our IDEs don't yet support it, because, rather new.
- zahlman 2y ago
  What exactly do you imagine that such "recognition" would entail? Are you expecting the IDE to provide its own package manager, for example?

BeetleB 2y ago

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".

claytonjy 2y ago
It does replace pipenv. They might not mention it because it's not widely used these days; most pipenv users switched to poetry sometime over the last half-decade or so. There is a request for `uv shell` or similar[0], but it's trickier than it looks, and even poetry gave up `poetry shell` in their recent 2.0 release. [0]: https://github.com/astral-sh/uv/issues/1910 https://github.com/astral-sh/uv/issues/1910
skeledrew 2y ago
I use autoenv, which runs a .env file when switching to a folder with it, and of course it has an activation command.
krupan 2y ago
Use direnv for automatically creating, activating, and deactivating your virtual environments. I don't know how anyone lives any other way. Just put this in a .envrc file (substituting whichever python version you are using): layout python python3.12 pip install --upgrade pip python -m pip install -r requirements.txt Looks like direnv can be extended to use uv: https://github.com/direnv/direnv/wiki/Python#uv https://github.com/direnv/direnv/wiki/Python#uv
BiteCode_dev 2y ago
You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.
- selectnull 2y ago
  While working in Django projects, one would prefer to have an environment activarted to perform all kinds of django-admin commands, I certainly wouldn't want to do via `uv run`. Also, `nvim` is started with an environment activated if you want all the LSP goodies. `uv run` is good for some things, but I prefer to have my venv activated as well.

deleted 2y ago

[deleted]

k2enemy 2y ago

uv is just so damn good. All else equal, I prefer julia to python, but uv makes the python experience so much nicer. I'd love it if julia copied uv and replaced the Pkg system with it.

sidpatil 2y ago
What are some of the issues you've had with the Pkg system?

claytonjy 2y ago

A scenario for "don't use uv" I hope none of you encounter: many nvidia libraries not packaged up in something better like torch. Here's just one example, nemo2riva, the first in several steps to taking a trained NeMo model and making it deployable: https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#export-nemo-models-to-riva-with-nemo2riva https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#... before you can install the package, you first have to install some other package whose only purpose is to break pip so it uses nvidia's package registry. This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit. This is of course not Astral's fault, I don't expect them to handle this, but uv has spoiled me so much it makes anything else even more painful than it was before uv.

ziml77 2y ago
Surely you can just manually add their index, right?
- zahlman 2y ago
  Yes, but the point is that they automate the process for you, because it's finicky.
- claytonjy 2y ago
  yes, but if you’re not in their carefully directed “nemo environment” the nemo2riva command fails complaining about some hydra dependency. and on it goes…
lijok 2y ago
Instead of installing nvidia-pyindex, use https://docs.astral.sh/uv/configuration/indexes/ https://docs.astral.sh/uv/configuration/indexes/ to configure the index nvidia-pyindex points to.
zahlman 2y ago
>whose only purpose is to break pip so it uses nvidia's package registry. This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit. I guess you're really talking about `nvidia-pyindex`. This works by leveraging the legacy Setuptools build system to "build from source" on the user's machine, but really just running arbitrary code. From what I can tell, it could be made to work just as well with any build system that supports actually orchestrating the build (i.e., not Flit, which is designed for pure Python projects), and with the modern `pyproject.toml` based standards. It's not that it "doesn't work with uv"; it works specifically with Pip, by trying to run the current (i.e.: target for installation) Python environment's copy of Pip, calling undocumented internal APIs (`from pip._internal.configuration import get_configuration_files`) to locate Pip's config, and then parsing and editing those files. If it doesn't work with `uv pip`, I'm assuming that's because uv is using a vendored Pip that isn't in that environment and thus can't be run that way. Nothing prevents you, incidentally, from setting up a global Pip that's separate from all your venvs, and manually creating venvs that don't contain Pip (which makes that creation much faster): https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... But it does, presumably, interfere with hacks like this one. Pip doesn't expose a programmatic API, and there's no reason why it should be in the environment if you haven't explicitly declared it as a dependency - people just assume it will be there, because "the user installed my code and presumably that was done using Pip, so of course it's in the environment".

d3v1an7 2y ago

great write up! have only dabbled in python, but dabbled enough to understand and _feel_ each dotpoint under "what problems uv tries to solve".

digdugdirk 2y ago

I'm very much looking forward to their upcoming static type checker. Hopefully it will lead to some interesting new opportunities in the python world!

MassPikeMike 2y ago

I have seen references to using uv for Python package management before and been thoroughly confused. I never realized it was not the same thing as the very nice asynchronous cross-platform library libuv (https://libuv.org/ https://libuv.org/) and I could never figure out what that library had to do with Python package management (answer: nothing). Maybe we need a Geographic Names Board to deconflict open source project names, or at least the ones that are only two or three characters long.

iandanforth 2y ago

Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable. You don't have to love uv, and there are plenty of reasons not to.

data_ders 2y ago
conda user for 10 years and uv skeptic for 18 months. I get it! I loved my long-lived curated conda envs. I finally tried uv to manage an environment and it’s got me hooked. That a projects dependencies can be so declarative and separated from the venv really sings for me! No more meticulous tracking of a env.yml or requirements.txt just ‘uv add` and `uv sync` and that’s it! I just don’t think about it anymore
- synparb 2y ago
  I'm also a long time conda user and have recently switched to pixi (https://pixi.sh/ https://pixi.sh/), which gives a very similar experience for conda packages (and uses uv under the hood if you want to mix dependencies from pypi). It's been great and also has a `pixi global` similar to `pipx`, etc the makes it easy to grab general tools like ripgrep, ruff etc and make them widely available, but still managed.
  - data_ders 2y ago
    whoa! TIL thanks will check it out
falcor84 2y ago
> I find nothing innovative or pleasing in its design, nor do I feel that it is particularly intuitive or usable. TFA offers a myriad innovative and pleasing examples. It would have been nice if you actually commented on any of those, or otherwise explained why you think otherwise.

triyambakam 2y ago

I didn't find any mention comparing it to rye. Anyone have any insight? I am pretty distant from the day to day Python ecosystem lately

LordKeren 2y ago
The astral team, creators of uv, have also subsumed rye So it’ll get rolled into UV
ilyagr 2y ago
Rye is softly being sunset in favor of `uv` (though still officially supported, and I haven't heard of any plans to change that). As it says on https://rye.astral.sh/ https://rye.astral.sh/, > If you're getting started with Rye, consider uv, the successor project from the same maintainers. > While Rye is actively maintained, uv offers a more stable and feature-complete experience, and is the recommended choice for new projects. It also links to https://github.com/astral-sh/rye/discussions/1342 https://github.com/astral-sh/rye/discussions/1342.

jquaint 2y ago

I excited to try uv for my next project. It seems like a good future proof way to package python packages in Nix. https://github.com/pyproject-nix/uv2nix https://github.com/pyproject-nix/uv2nix

emseetech 2y ago

I can't speak to uv from an app dev perspective (I use Go for that), but as someone who dips into the Python world for data science reasons only, uv is great and I'm thankful for it.

ijustlovemath 2y ago

How are they handling the returns VCs expect through this free software? If it's so easy to deploy, surely we should expect a Docker-like licensing model in the near future?

ashishb 2y ago

Has someone migrated from poetry to uv? Any benefits?

JodieBenitez 2y ago
Yes. The main benefits for me and my coworkers are speed and automatic fetching of Python interpreter. It's so fast that it's a pleasure to use (same thing could be said about ruff vs. black). And the fact that it downloads the right Python interpreter specified in the project's pyproject.toml means my coworker don't have to care about installing and managing Python versions. They don't even need to have a Python installed in the first place. Otherwise, it works pretty much like Poetry. Unfortunately Poetry is not standards-compliant with the pyproject.toml, so you'll have to rewrite it. There are tools for this, never bothered with them though.
BiteCode_dev 2y ago
Mostly less modes of failures, particularly at bootstrapping.
dagw 2y ago
In addition to all the benefits others have mentioned, biggest benefit for me was that with uv you can easily bring your own build system (scikit-build-core in my case). Poetry comes with its own build system that didn't work for my needs and working around that was a massive pain and quite fragile. With uv I can use the build system that works best for me. On the whole uv is less opinionated than poetry. By default it will do sensible things, but if that thing doesn't work in your particular weird case, it is much easier to make uv work for you than poetry. Poetry gets very angry if you try to hold it wrong.

lysecret 2y ago

Really like uv too but surprised he doesn’t mention the lack of conda compliance. Some scientific packages only being available on conda is the only reason I can’t use uv (but micromamba) for some projects.

BiteCode_dev 2y ago
conda compiance is nearly impossible to get because the typical anaconda project doesn't exist: it's a separate ecosystem with huge variability that is by design incompatible with everything else and that no two teams use in the same way.

__rito__ 2y ago

Is there a conda to uv migration tutorial written by anyone? I have installed miniconda system-wide. For any Python package that I use a lot, I install them on base environment. And on other environments. Like ipython. For every new project, I create a conda environment, and install everything in it. Upon finishing/writing my patch, I remove that environment and clean the caches. For my own projects, I create an environment.yaml and move on. Everything works just fine. Now, the solving with mamba is fast. I can just hand someone the code and environment.yaml, and it runs on other platforms. Can someone say why using uv is a good idea? Has anyone written a migration guide for such use cases? I am mightily impressed by one line dependency declaration in a file. But I don't know (yet) where the caches are stored, how to get rid of them later, etc.

BrenBarn 2y ago

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 conda doesn't seem to have which uv has is all the "project management" stuff. Which is fine, it's clear people want that. But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.) The pro and con of tools like uv is that they layer over the base-level tools like pip. The pro of that is that they interoperate well with pip. The con is that they inherit the limitations of that packaging model (notably the inability to distribute non-Python dependencies separately). That's not to say uv is bad. It seems like a cool tool and I'm intrigued to see where it goes.

necessary 2y ago
The killer feature of uv for me is much faster uv pip install -r requirements.txt.
agent281 2y ago
> But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.) I used conda for awhile around 2018. My environment became borked multiple times and I eventually gave up on it. After that, I never had issues with my environment becoming corrupted. I knew several other people who had the same issues and it stopped after they switched away from conda. I've heard it's better now, but that experience burned me so I haven't kept up with it.
uneekname 2y ago
Yes, conda has a lot more features on paper. And it supports non-Python dependencies which is super important in some contexts. However, after using conda for over three years I can confidently say I don't like using it. I find it to be slow and annoying, often creating more problems than it solves. Mamba is markedly better but still manages to confuse itself. uv just works, if your desktop environment is relatively modern. that's its biggest selling point, and why I'm hooked on it.

upbeat_general 2y ago

I tried out uv a bit ago and dropped it. But about two weeks ago, I switched to it and migrated two projects with no issues. Things like pypi sources per dep are there finally. I still find rough points (as many others pointed out, especially with non sandboxed installs), that are problematic, but on the whole it’s better than Mamba for my use.

motorest 2y ago

I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/ https://libuv.org/

inejge 2y ago
I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. (The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)
- sph 2y ago
  Sure, there are so few backend Node.js engineers. Let alone game engine developers and Blender users with their UV mapping tools. None of these people will ever encounter Python in their daily lives.
  - wiseowise 2y ago
    [flagged]
    - hu3 2y ago
      That's unnecessarily rude.
- nonameiguess 2y ago
  I'm not sure that's true. uvloop, built on libuv, is a pretty popular alternative event loop for async Python, much faster than the built-in. It certainly confused me at first to see a tool called "uv" that had nothing to do with that, because I'd been using libuv with Python for years before it came out.
- motorest 2y ago
  > I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. Google returns mixed results. You may assert it's not problematic, but this is a source of noise that projects with distinct names don't have.

tiltowait 2y ago

The challenge I have with adopting uv is it feels like it doesn't have a great replacement for poetry's `[tool.poetry.scripts]` block. For instance, from a personal project that uses a src layout, without being a package, I have this in my pyproject.toml: [tool.poetry] ... packages = [{ include = "*", from = "src", format = "sdist" }] ... [tool.poetry.scripts] botch = "launcher:run_bot('botch')" beat = "launcher:run_bot('beat')" I can't find any way to get that working in uv without some pretty major refactoring of my internal structure and import declarations. Maybe I've accidentally cornered myself in a terrible and ill-advised structure?

simonw 2y ago
It looks like uv will get script support eventually: https://github.com/astral-sh/uv/issues/5903 https://github.com/astral-sh/uv/issues/5903
semi-extrinsic 2y ago
You can do this: [project.scripts] hello = "example:hello" Assuming you have src/example.py with a function called hello, then "uv run hello" will call that function. I think you also need to have a (empty) src/__init__.py file.
zahlman 2y ago
[project.scripts] is the PEP621 equivalent, supported by multiple backends including vanilla Setuptools. (When you use [tool.poetry.scripts], it's really the build backend, Masonry, that cares.) So that's the uv way, too. Or the "bear skins and stone knives" way. I don't know what you mean by "without being a package". I guess you mean that Poetry will also run your code without installing it anywhere, and use the marked entry points directly. Per the other replies, apparently uv will get an equivalent soon. But really, the point of having `pyproject.toml` in the first place is to explain how to build an installable wheel and/or sdist for your project, and you basically get it for free. (Even if you don't include a [build-system] table, the standards say to use Setuptools by default anyway.) (Of course, uv can already `run` your entry point, but this involves installing the code in a temporary venv.) > without some pretty major refactoring of my internal structure and import declarations. Maybe I've accidentally cornered myself in a terrible and ill-advised structure? Possibly. Is the code up on GitHub? I could take a look.

microflash 2y ago

uv has been fantastic for most of my personal projects. It feels so much smoother than any other python tooling combo I tried in past. That said, it just does not work well behind corporate proxies. This is single most annoying thing that has stopped me from recommending it at work.

speakspokespok 2y ago

Has anyone built pipy packages with `uv`? Does doing so affect the end-user at all?

simonw 2y ago
What do you mean by building a pipy package? If you mean creating and publishing packages to PyPI end users can't tell if you used uv or poetry or something else.
trallnag 2y ago
Works fine. But for people on Github for now I recommend using uv only for building distributions and using the official PyPA GitHub action for publishing them to PyPI. This way you can take advantage of attestation, something not yet supported by uv.

datadeft 2y ago

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.

gyomu 2y ago
What’s a good flask (+jinja) equivalent for rust?
- selectnull 2y ago
  Actix + minijinja Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.
- datadeft 2y ago
  I use Axum and Askama for such usecases.
wiseowise 2y ago
Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?
- datadeft 2y ago
  Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.
  - lmm 2y ago
    You can get pretty far without needing to run pip. Whereas you can't change anything in a rust codebase without compiling it.
procaryote 2y ago

shlomo_z 2y ago

A familiar tale: Joe is hesitant about switching to UV and isn't particularly excited about it. Eventually, he gives it a try and becomes a fan. Soon, Joe is recommending UV to everyone he knows.

EdwardDiego 2y ago
Joe has found the One True God, Joe must proselytise, the true God demands it.

mherrmann 2y ago

> There are a lot of different ways to install Python, all with different default settings, and gotchas. With uv, there is now one more. https://xkcd.com/927/ https://xkcd.com/927/

vaylian 2y ago
Arnim Ronacher, author of rye (later uv) has very clearly highlighted that exact xkcd when he started working on rye. But he still decided that it was worth a try and as it turns out, rye/uv has become something that has a realistic chance of becoming the way to use python for most use-cases.
- mherrmann 2y ago
  Cool point, thank you. I think his name is Armin.
  - vaylian 2y ago
    Thanks. You are right. Unfortunately I can't edit my post any longer.

egorfine 2y ago

Can anyone explain to a non-python developer why python infrastructure is so much broken around the version management? It looks to me that every new minor python release is a separate additional install because realistically you cannot replace python 3.11 with python 3.12 and expect things to work. How did they put themselves in such a mess?

cpburns2009 2y ago
Python code rarely breaks between minor version releases in my experience. Python 3.5 introduced the `async` keyword (PEP 492), and Python 3.7 changed `StopIteration` handling in generators (PEP 479).

davedx 2y ago

Astral is doing phenomenal work. I'm extremely excited about the ruff type checker too.

DoingIsLearning 2y ago

As a dabbler (using python mostly for internal engineering tools and post processing of data) I am using uv at home but not in a professional setting. The latest release is at 0.6.1, what is missing (roadmap/timeline wise) for uv to exist as a 1.0 release?

meindnoch 2y ago

Ok, so apparently `uv` has nothing to do with `libuv`.

BiteCode_dev 2y ago

Author here. A.m.a

tartieret 2y ago
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!)
- BiteCode_dev 2y ago
  uv export?

antirez 2y ago

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.

nickelpro 2y ago
This is not packaging hell, this is you having a personal problem with how other developers work. Python has come an immensely long way in the world of packaging, the modern era of PEP 517/518 and the tooling that has come along with it is a game changer. There are very few language communities as old as Python with packaging ecosystems this healthy. I've had conversations with members of SG15, the C++ tooling subgroup, where Python's packaging ecosystem and interfaces are looked on enviously as systems to steal ideas from.

gkfasdfasdf 2y ago

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?

roland35 2y ago
You probably need to make sure you have the correct python version set. By default it is in the .venv directory with uv
_whiteCaps_ 2y ago
I start a shell with "uv run bash" and start neovim from there. I'm sure there's other ways but it's a quick fix and doesn't involve mucking around with neovim config.
- gkfasdfasdf 2y ago
  That's brilliant, thanks! EDIT - 'uv run nvim' works also

torcete 2y ago

uv, venv, conda, brew, deb, nix, guix, chocolatey, containers, jails... One day we will finally find the ONE solution to this problem.

greenie_beans 2y ago
call it: one

evanwpm 2y ago

uv has been a complete game changer for me in Python, everyone who develops with me knows I won't shut up about it. Astral is a great team, they built the ruff linter and are currently working on a static type checker called red-knot: https://x.com/charliermarsh/status/1884651482009477368 https://x.com/charliermarsh/status/1884651482009477368

nchmy 2y ago

Just going to plug https://mise.jdx.dev https://mise.jdx.dev as a perfect accompaniment to uv. It simplifies installing tooling across languages and projects. I even install uv via mise, and it uses uv under the hood for Python related things.

perrygeo 2y ago

> You don't even need to know there is a venv, or what activation means. > All those commands update the lock file automatically and transparently.... It's all taken care of. When is the python community going to realize that simple is the opposite of easy? I don't see how hiding these aspects is desirable at all; I want to know how my programming tools work! With all due respect to the author, I don't like the assumption that all programmers want magic tools that hide everything under the rug. Some programmers still prefer simplicity, ie understanding exactly what every part of the system does. Nothing against uv, it seems like a fine tool. And I'm sure one could make a case for it on other technical merits. But choosing it specifically to avoid critical thinking is self-defeating.

ijustlovemath 2y ago
I think that when you, as most HN commenters are wont to do, are trying to achieve a certain level of mastery in your craft, you're going to want to dive deep, understand the abstractions, have full control, be able to start with nothing but a UDP socket and a steady hand, but that approach misses a huge number of users of these languages. You don't want scientists to have to worry about setting up a venv, you want them to analyze their data and move on with their lives. Sure, people like you or me will be able to setup and source a venv in no time, without expending much mental energy, but we're not who this product is for. It's for the rest of the users, the 99% who aren't even aware places like this exist. All that said, I'm pretty skeptical of using uv until their monetization strategy is clear. The current setup is making me think we're in for a Docker-like license change.
392 2y ago
There is simplicity of interface and then of implementation. If you try uv you will find it is both convenient and easier to understand than competing solutions, because everything _just works_ and you find the proof of how it works waiting in your `git status`. You can be assisted in knowing that it just works because its install takes no time and no system setup. It is slick.
zahlman 2y ago
A recurring theme I've seen in Python packaging community discussion is that a lot of people really seem to hate venvs, mostly for reasons I consider quite irrational. And if they don't outright hate the things, they fear having to try to explain them to newbies. Keep in mind: there are huge numbers of people out there who will cargo-cult about how applying the sudo hammer to Pip fixed something or other (generally, because the root user has different environment variables). People even resent having to do user-level installations; they resent venvs even more. When the Python team collaborated with multiple Linux distros to add a system to protect against global user-level installs (because they were still interfering with system Python tools), a lot of people reacted by doing whatever they could to circumvent that protection, and advising each other on how to do so - thus the education effort described in https://discuss.python.org/t/the-most-popular-advice-on-the-internet-for-error-externally-managed-environment-is-to-force-packages-to-be-system-installed/56900 https://discuss.python.org/t/the-most-popular-advice-on-the-... . People really would, apparently, rather add `--break-system-packages` to a command line so that they can keep installing everything in the same place, than attempt to understand even the basics of environment management. And we're talking about programmers here, mind. And then there are the complaints about how the __pypackages__ proposal (https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/) failed - e.g. https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/#pep-582-the-future-of-python-packaging https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth... . There were serious issues with that idea, which only became clear as the discussion dragged on and on across literally years (https://discuss.python.org/t/pep-582-python-local-packages-directory/963 https://discuss.python.org/t/pep-582-python-local-packages-d...). But people were quite upset about having to stick with the old venv model - including the guy who wrote the best explanation of venvs I know, which I frequently refer beginners to (https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi...). A lot of programmers seem to love having the details not only hidden, but as inaccessible as possible, as long as the UI is nice enough. (Unless we're talking about their own code. Then, hundred-line functions are just hunky-dory.)

deleted 2y ago

[deleted]

remram 2y ago

The problem I have with uv is that it is not opinionated enough, or complete enough. It still needs a backend for building the package, and you still have a choice of backends. In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how to do x/y/z. You'll still have to switch from hatchling to flit/pdm/setuptools/... if you run into a limitation of hatchling. As a package author, you're never using uv, you're using uv+hatchling (or uv+something) and a big part of your pyproject.toml are not uv's configuration, it is hatchling configuration. I'm sticking with Poetry for now, which has a more streamlined workflow. Things work together. Every Poetry project uses the same configuration syntax (there are no Poetry+X and Poetry+Y projects). Issues in Poetry can be fixed by Poetry rather than having to work with the backend. I understand that uv is still young and I am sure this will improve. Maybe they'll even pick a specific backend and put a halt to this. But of course Poetry might catch up before then.

ofek 2y ago
Hatchling maintainer here :) What limitations have you personally experienced?
tmvphil 2y ago
They are currently in the process of creating their own build system: https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266 https://github.com/astral-sh/uv/issues/3957#issuecomment-265...
zahlman 2y ago
>In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how to do x/y/z. You'll still have to switch from hatchling to flit/pdm/setuptools/... if you run into a limitation of hatchling. As a package author, you're never using uv, you're using uv+hatchling (or uv+something) and a big part of your pyproject.toml are not uv's configuration, it is hatchling configuration. Strange. The main reason I'm not using uv or its competitors (or going back to Poetry, where I was using only a tiny fraction of the functionality) is that they're all too opinionated and all-in-one for me. If I had to write down a top 10 of reasons the Python packaging ecosystem is a "mess", and give detailed reasoning, probably at least 6 of them would be problems with Pip specifically (including things that appear to be problems in other tools, but which are really Pip's fault). And at least one more would be "Setuptools is a massive pile of backwards-compatibility wrappers that are mostly useless with the modern packaging flow, that didn't even directly make the wheels (relying on a separate dependency instead) until 70.1". (The other reason I wouldn't go back to Poetry is because Masonry was a terrible, non-standards-compliant experience for me, and its installation procedures changed repeatedly over time, and you'd end up not being able to uninstall old versions cleanly.) (Hatchling and Setuptools are build backends, yes; where you say "flit" I assume you mean flit-core, and similarly pdm-backend for PDM.) If uv provided its own backend, there would still be a risk of running into limitations with that backend; and regardless you'd have to go through its docs to figure out how to do x/y/z with it. Being able to experiment with different build backends was part of the explicit rationale for `pyproject.toml` in the first place. The authors of PEP 517 and 518 consciously expected to see competing backends pop up (and explicitly designed a system that would allow that competition, and allow for Pip etc. to know how to invoke every backend), and did not (per my understanding of Python Discourse forum discussion) consciously expect to see competing workflow tools pop up. I'm making a build backend because I have my own opinion. I don't have any interest in making a workflow tool. I want people who like uv to be able to use my build backend. That's how the system was designed to work. I don't want someone to integrate the baseline and make all the decisions for me. I want a better-quality baseline. Which is why I'm also making an installer/environment manager. `build` is a perfectly fine build frontend. I don't need or want a replacement.

zellyn 2y ago

I've been using Hermit to install uv, then pointing scripts at $REPO_ROOT/bin/uv. That gives you a repo where the scripts can be run directly after cloning (Hermit is smart enough to install itself if necessary). Unfortunately, Hermit doesn't do Windows, although I'm pretty sure that's because the devs don't have Windows machines: PRs welcome. https://github.com/cashapp/hermit https://github.com/cashapp/hermit

mathisd 2y ago

I really like uv and I have successfully got rid of miniconda but : - I wish there was a global virtual environment which could be referenced and activated from terminal. Not every new scripts needs their own .venv in their respective folder. uv takes the route of being project centered and based on file system, this works for me most of the time but sometime it doesn't. - I wish we could avoid the .python_version file and bundle it in the pyproject.toml file.

auxym 2y ago
Agreed, I like to have a "general use" environment to use for various one-off interactive python sessions, scripts or jupyter notebooks.