43 ms·

Uv's killer feature is making ad-hoc environments easy

502 points by astronautas 2y ago

instig007 2y ago
wow, they've re-invented a tiny bit of Nix, purely legend!
- smallmancontrov 2y ago
  A few months ago I saw someone hacking the linker to get mundane package management working in Nix. It was bubbling up to the top of my "to try" list and that bumped it back down. It'll be good eventually, I'm sure.
  - instig007 2y ago
    > It'll be good eventually, I'm sure. not with this attitude of getting scared of things by watching someone doing something, for sure
    - smallmancontrov 2y ago
      I have fixed enough (dynamic) linker issues for this lifetime and probably several more. I think I'll let the kids take these. Godspeed.
- lucsky 2y ago
  That you can use without having 4 PhDs. It's pretty good. You should try it sometime when your done fully ingesting algebraic topology theory or whatever the fuck Nix requires to know just to install figlet.
  - 331c8c71 2y ago
    Oh come on, it's not that hard even for packaging stuff (let alone usage). Quite trivial compared to leetcode grind I'd say.
    - amelius 2y ago
      Everybody will reinvent Nix if they are in software engineering long enough ...
      - 331c8c71 2y ago
        If only... Majority will use whatever is shoved up their a## be it docker or anything else.
    - sgarland 2y ago
      You say that, but there seems be a vast chasm between “can solve LC hards” and “can administer an OS,” even though the latter is generally not at all abstract, extremely well-documented, and almost certainly has associated man pages.
  - Evidlo 2y ago
    Try flox [0]. It's an imperative frontend for Nix that I've been using. I don't know how to use nix-shell/flakes or whatever it is they do now, but flox makes it easy to just install stuff. [0]: https://flox.dev/ https://flox.dev/
  - instig007 2y ago
    > You should try it sometime when your done fully ingesting algebraic topology theory or whatever the fuck Nix requires to know aka how to say that you've never really tried learning Nix without saying it directly.
- forrestthewoods 2y ago
  Nix people are more annoying than Rust Defense Force. I use Windows, and not WSL. Nix does literally nothing for me.
  - instig007 2y ago
    [flagged]
    - forrestthewoods 2y ago
      There’s vastly more Windows devs than you realize. Vastly.
lukax 2y ago
Uv also bundles uvx command so you can run Python scripts without installing them manually: uvx --from 'huggingface_hub[cli]' huggingface-cli
- astronautas 2y ago
  Neat!
- oulipo 2y ago
  And there's also the `uv run script.py` where you can have dependencies indicated as comments in the script, see eg https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
tasn 2y ago
OK, I'm convinced. I just installed uv. Thanks for sharing!
- smallmancontrov 2y ago
  Ditto. This is pretty cool!
retroflexzy 2y ago
uv implements PEP 723. https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... Especially useful if the script has dependencies on packages in private repos.
supakeen 2y ago
The activation of the virtualenv is unnecessary (one can execute pip/python directly from it), and the configuring of your local pyenv interpreter is also unnecessary, it can create a virtual environment with one directly: pyenv virtualenv python3.12 .venv .venv/bin/python -m pip install pandas .venv/bin/python Not quite one command, but a bit more streamlined; I guess.
- astronautas 2y ago
  Indeed, you're right ;).
- BeeOnRope 2y ago
  Note that in general calling the venv python directly vs activating the venv are not equivalent. E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.
  - meitham 2y ago
    Surely if you want to invoke python you call sys.executable otherwise if your subprocess doesn’t inherit PATH nothing will work with uv or without uv
    - zahlman 2y ago
      In rare cases, programs might also care about the VIRTUAL_ENV environment variable set by the activate script, and activation may also temporarily clear out any existing PYTHONHOME (a rarely used override for the location of the standard library). But yes, in general you can just run the executable directly.
    - BeeOnRope 2y ago
      I don't think that's "sure" at all. For one thing, only Python code directly calling Python has that option in the first place, often there is another layer of indirection, e.g., Python code which executes a shell script, which itself invokes Python, etc. IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.
dang 2y ago
I've replaced the linkbait title with an attempt at saying what the feature is. If there's a more accurate wording, we can change it again.
- astronautas 2y ago
  uh, thanks I guess.
  - astronautas 2y ago
    How about "A UV feature that intrigues me most"?
    - airstrike 2y ago
      Still clickbait if you don't say what the feature is.
    - minimaxir 2y ago
      That's still clickbait, although less tropey. The common definition of clickbait is intentionally omitting information that incentives the user to click.
  - dang 2y ago
    It's just standard practice here. See https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
    - astronautas 2y ago
      see my reply above
- zanie 2y ago
  I don't feel strongly, but as a uv author, I found "local dependencies" misleading. It's more like "uv's killer feature is making ad-hoc environments easy". When we talk about local dependencies in the Python packaging ecosystem, it's usually adding some package on your file system to your environment. The existing title made me think this would be about the `[tool.uv.sources]` feature. Really, it's about how we create environments on-demand and make it trivial to add packages to your environment or try other Python versions without mutating state.
nharada 2y ago
I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you could use conda too"
- poincaredisk 2y ago
  I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
  - mplewis 2y ago
    Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
    - aidos 2y ago
      I’ve always worked around that by having a requirements.base.txt and a requirements.txt for the locked versions. Obviously pip doesn’t do that for you but it’s not hard to manage yourself. Having said that, I’m going to give uv a shot because I hear so many good things about it.
      - mikepurvis 2y ago
        I’m grouchy because I finally got religion on poetry a few years ago, but the hype on uv is good enough that I’ll have to give it a shot.
        kstrauser 2y ago
        I freaking love Poetry. It was a huge breath of fresh air after years of pip and a short detour with Pipenv. If uv stopped existing I’d go back to Poetry. But having tasted the sweet nectar of uv goodness, I’m onboard the bandwagon.
faizshah 2y ago
I love this, the biggest problem I have right now with python scripts is distributing my single file utility scripts (random ops scripts). I wish there was a way to either shebang something like this or build a wheel that has the full venv inside.
- delusional 2y ago
  You are in luck https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
- easton 2y ago
  There’s a shebang now. as of PEP 722 you can declare dependencies in a comment at the top of a single file script that a package manager can choose to read and resolve. uv has support for it: https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies https://docs.astral.sh/uv/guides/scripts/#running-a-script-w... (which only helps if your team is all in on uv, but maybe they are)
  - eesmith 2y ago
    PEP 722 was rejected. You are thinking of PEP 723, which was very similar to 722 in goals. https://discuss.python.org/t/pep-722-723-decision/36763 https://discuss.python.org/t/pep-722-723-decision/36763 contains the reasoning for accepting 723 and rejecting 722.
  - miohtama 2y ago
    Do other package managers support this yet?
    - zahlman 2y ago
      Pipx isn't in any meaningful sense a package manager (although it can manage environments to a limited extent), but the `pipx run` command supports this PEP as of version 1.4.2.
  - amelius 2y ago
stevage 2y ago
As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
- mdaniel 2y ago
  Caveat: I'm a node outsider, only forced to interact with it But there are a shocking number of install instructions that offer $(npm i -g) and if one is using Homebrew or nvm or a similar "user writable" node distribution, it won't prompt for sudo password and will cheerfully mangle the "origin" node_modules So, it's the same story as with python: yes, but only if the user is disciplined Now ruby drives me fucking bananas because it doesn't seem to have either concept: virtualenvs nor ./ruby_modules
  - andrewmcdonough 2y ago
    Ruby has a number of solutions for this - rvm (the oldest, but less popular these days), rbenv (probably the most popular), chruby/gem_home (lightweight) or asdf (my personal choice as I can use the same tool for lots of languages). All of those tools install to locations that shouldn't need root.
    - mdaniel 2y ago
      Yes, I am aware of all of those, although I couldn't offhand tell anyone the difference in tradeoffs between them. But I consider having to install a fresh copy of the whole distribution a grave antipattern. I'm aware that nvm and pyenv default to it and I don't like that I did notice how Homebrew sets env GEM_HOME=<Cellar>/libexec GEM_PATH=<Cellar>/libexec (e.g. <https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f7e7cca264f406a370b3fb967ee4/Formula/f/fastlane.rb#L35-L36 https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f...>) but, similar to my node experience, since I am a ruby outsider I don't totally grok what isolation that provides
  - MrJohz 2y ago
emiller88 2y ago
There's so many more! 1. `uvx --from git+https://github.com/httpie/cli https://github.com/httpie/cli httpie` 2. https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/ https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/ uv in a shebang
- throwup238 2y ago
  The uv shebang is definitely the killer feature for me, especially with so much of the AI ecosystem tied up in Python. Before, writing Python scripts was a lot more painful requiring either a global scripts venv and shell scripts to bootstrap them, or a venv per script. I’m sure it was already possible with shebangs and venv before, but uv really brings the whole experience together for me so I can write python scripts as freely as bash ones.
- FergusArgyll 2y ago
  Yes! since that Simon Willison article, I've slowly been easing all my scripts into just using a uv shebang, and it rocks! I've deleted all sorts of .venvs and whatnot. really useful
- dingdingdang 2y ago
  Super neat re Willison article.. would something like this work under powershell though?!
curiousgal 2y ago
uv has does not (nor do they plan to add) support for conda, and that is a deal-breaker.
- throwaway314155 2y ago
  That doesn't make sense, respectfully.
- PaulHoule 2y ago
  I can't see why anyone is using Conda in 2025. In 2018, yeah, pip (now uv) was hard and you could get a "just works" experience installing Tensorflow + NVIDIA on Conda. In 2023 it was the other way around and it still is.
  - curiousgal 2y ago
    Well, when you're building python packages that have non python dependencies and a big chunk of your users are on Windows, conda is the only option, even in 2025 :) Examples include, quant libraries, in-house APIs/tools, etc.
    - amelius 2y ago
      Conda worked for me in the past, but at some point I was getting inexplicable segfaults from Python scripts. I switched back to just pip and everything worked fine again. And installation was much faster.
      - PaulHoule 2y ago
        That was basically my experience. At one time conda made my life easier, eventually it made it impossible.
    - PaulHoule 2y ago
      Circa 2018, I figured out how to pack up the CUDA libraries inside conda for Windows so I could have different conda environments with different versions of CUDA which was essential back then because if you had a model that was written w/ a certain version of Tensorflow you had to have a matching CUDA and if you used NVIDIA's we-need-your-email-address installers you could only have one version of CUDA installed at a time. Worked great except for conda making the terrible mistake of compressing package files with bzip2 which took forever to decompress for huge packages. I see no reason you can't install any kind of non-Python thing that a Python system wants with uv because a wheel is just a ZIP file, so long as it doesn't need to be installed in a particular place you can just unpack it and go.
minimaxir 2y ago
What would be interesting is if you could do something similar for IPython/Jupyter Notebooks: while front-ends like JupyterLab and VS Code Notebooks do let you select a .venv if present in the workspace, it's annoying to have to set one up and build one for every project.
- mirekrusin 2y ago
  https://github.com/manzt/juv https://github.com/manzt/juv
riwsky 2y ago
Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
- aeurielesn 2y ago
  I don't understand how things like this get approved into PEPs.
  - zanie 2y ago
    As in, you think this shouldn't be possible or you think it should be written differently?
  - Karupan 2y ago
    Seems like a great way to write self documenting code which can be optionally used by your python runtime.
  - linsomniac 2y ago
    I don't think this IS a PEP, I believe it is simply something the uv tool supports and as far as Python is concerned it is just a comment.
    - mkl 2y ago
      https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
      - linsomniac 2y ago
        Thank you for the pointer, I had searched for it but couldn't find it. (edit: Glad I spent the downvotes to get educated :-)
    - zanie 2y ago
laidoffamazon 2y ago
I honestly really hate the venv ergonomics but uv does still depend on it as the golden path if you don’t use the —with flags (in my understanding). Is there a way to do a clean break with just the new —script inline dependencies, or is that wrong/suboptimal?
- zanie 2y ago
  You can definitely do that — it's just sub-optimal when you have multiple files that share dependencies.
aizk 2y ago
one useful UV alias I use is uvsys='uv pip install --system' So I can just do uv {package} for a quick and dirty global install. I'm so used to pip install being global by default just making this shorthand makes things a bit easier.
- claytonjy 2y ago
  this sounds like it’s asking for trouble! very easy to mess up your whole system i would highly recommend only using —-system in a docker container or similar
amelius 2y ago
Sometimes, only a specific wheel is available (e.g. on Nvidia's Jetson platform where versions are dictated by the vendor). Can uv work with that?
valcron1000 2y ago
Can you also specify which version of pandas to use?
- zanie 2y ago
  Of course! uv run -q --with pandas==2.1.4 python -c "import pandas; print(pandas.__version__)" 2.1.4
secondcoming 2y ago
[flagged]
- zahlman 2y ago
  >you need a virtual environment for some reason You have always needed on, practically speaking. Python isn't designed to have multiple versions of the same library in the same runtime environment. A virtual environment is just a separate place to put the packages you need for the current project, so that they're isolated from other packages, and thus you don't get version conflicts. This includes the system packages. If you want to play with, say, the latest version of Requests, and you try sudo installing that in a system environment, and it happens that the latest version of Requests breaks Apt (which is written in Python), you're in for a bad time. The new warning is because even user-level installations can mess with system scripts, when those scripts are run without sudo. Also, Apt has no real way to know about or understand anything you do with Pip, so that interferes with Apt's actual package management. >installing packages [with] sudo doesn't make them available to other users If you use sudo to install packages for the system Python, then yes they absolutely are available to all users. But you don't see them in virtual environments by default (you can change this) because the default is to ignore the system installation's `site-packages` completely (including user-level installations). > on ubuntu it seems pip has been replaced with 'python-*' debian packages None of this is new, and it doesn't even remotely "replace" Pip. You're just facing a little more pressure to actually use the system package manager when installing packages for your system, since that can actually manage packages, and integrate them with the rest of your system (the non-Python parts). The Debian packages are specifically vetted and tested for this purpose and may include Canonical's own patches that you won't get from PyPI. On the other hand, PyPI provides vastly more different packages. When you install in a virtual environment, you'll generally use Pip to do it (unless you use uv etc.). Because the environment is specifically created to be isolated from your system, so that Apt doesn't have to care. Please see https://stackoverflow.com/questions/75608323 https://stackoverflow.com/questions/75608323 for details. It wasn't a snap decision; see https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/10302 https://discuss.python.org/t/pep-668-marking-python-base-env... for context. Arch implements analogous protections, too, for the same reasons (https://www.youtube.com/watch?v=35PQrzG0rG4 https://www.youtube.com/watch?v=35PQrzG0rG4). I recall Fedora having similar plans but I didn't hear about it being implemented yet.
mgd020 2y ago
Whats the point if you have other binary dependencies? Use Nix for Python version as well as other bin deps, and virtualenv + pip-tools for correct package dependency resolution. Waiting 4s for pip-tools instead of 1ms for uv doesn't change much if you only run it once a month.
sonium 2y ago
But I still need pip to install uv, right? Or download it using a one-liner alternatively.
- philomath_mn 2y ago
  You can install it in several ways without pip, easiest is standalone installer (which can upgrade itself) https://docs.astral.sh/uv/getting-started/installation/ https://docs.astral.sh/uv/getting-started/installation/
- dontdieych 2y ago
  cargo install
m3kw9 2y ago
That’s like a killer app type feature. However it says adhoc so you probably can’t get back to that setup easily
crispyambulance 2y ago
I do like uv and hope to try it soon but I don't get the point of the article. Pyenv + poetry already gives you ability to "pull in local dependencies". Yes, you have to create a virtual environment and it's not "ad-hoc". But if you're going to pull in a bunch of libraries, WHY would you want to invoke python and all your work dependencies on a one liner? Isn't it much better and easier to just spell-out the dependencies in a pyproject.toml? How "ad-hoc" are we talking here?
- wiseowise 2y ago
  Yes! I love verbosity. It gives me job security. I’m tired of these tools making my job easier. Previously I could allocate a whole week to setup initial scaffold for the project. Also more tools - more failure points, so I can flex on stupid juniors how smart I am. Now I can’t even go to pee with how fast and easy this freaking uv is. WTF.
  - crispyambulance 2y ago
    Well I guess I am not smart enough to dump multiple dependencies + python, densely, on one line to spin everything up so I can do “ad-hoc” computing without just spelling them out in a file. Sorry, but that just isn’t a killer feature for me and it doesn’t seem like a big deal anyway. I do like the idea of getting rid of pyenv though. And since poetry has failed to become as widespread as I hoped, maybe uv has a better shot?
misiek08 2y ago
Small misorder in the „right route” - you should first activate the virtual environment just created and then install pandas.
greatgib 2y ago
Ridiculous post: The author says that a normal route would be: - Take the proper route: - Create a virtual environment - pip install pandas - Activate the virtual environment - Run python Basically, out of the box, when you create an virtual it is immediately activated. And you would obviously need to have it activated before doing a pip install... In addition, in my opinion this is the thing that would sucks about UV to have different functions being tied to a single tool execution. It is a breeze to be able to activate a venv, and be done with it, being able to run multiple times your program in one go, even with crashes, being able to install more dependencies, test it in REPL, ...
- hamandcheese 2y ago
  You can still use traditional venvs with UV though, if you want.
  - krick 2y ago
    Uh, but then you don't really need uv, right?
    - hamandcheese 2y ago
      No, but it is insanely faster than pip.
- astronautas 2y ago
  Hey, I actually made a silly mistake in my post, indeed you first activate the environment and then install stuff in it. Fixed! I disagree though it is activated immediately, or at least to me with venv I always have to activate it explicitly.
cyrialize 2y ago
For anyone that used rye, it's worth noting that the creator of rye recommends using uv. Also, rye is going to be continually updated to just interface with uv until rye can be entirely replaced by uv.
- andelink 2y ago
  I believe they are from the same author, Charlie Marsh / Astral
  - BiteCode_dev 2y ago
    no armin created rye then gave it to astral
wruza 2y ago
Why can’t python just adopt something like yarn/pnpm + and effing stop patch-copying its binaries into a specific path? And pick up site_packages from where it left it last time? Wtf. How hard it is to just pick python-modules directory and python-project.json and sync it into correctness by symlink/mklink-inf missing folders from a package cache in there in a few seconds? Every time when I have to reorganize or upgrade my AI repos, it’s yet another 50GB writes to my poor ssd. Half of it is torch, another half auto-downloaded models that I cannot stop because they become “downloaded” and you never know how to resume it back or even find where they are cause python logging culture is just barbaric.
bityard 2y ago
I usually stay away far FAR from shiny new tools but I've been experimenting with uv and I really like it. I'm a bit bummed that it's not written in Python but other than that, it does what it says on the tin. I never liked pyenv because I really don't see the point/benefit building every new version of Python you want to use. There's a reason I don't run Gentoo or Arch anymore. I'm very happy that uv grabs pre-compiled binaries and just uses those. So far I have used it to replace poetry (which is great btw) in one of my projects. It was pretty straightforward, but the project was also fairly trivial/typical. I can't fully replace pipx with it because 'uv tool' currently assumes every Python package only has one executable. Lots of things I work with have multiple, such as Ansible and Jupyterlab. There's a bug open about it and the workarounds are not terrible, but it'd be nice if they are able to fix that soon.
- meitham 2y ago
  uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/ https://gregoryszorc.com/docs/python-build-standalone/main/
  - zahlman 2y ago
    >that very same project says this is compiled for portability over performance Realistically, the options on Linux are the uv way, the pyenv way (download and compile on demand, making sure users have compile-time dependencies installed as part of installing your tool), and letting users download and compile it themself (which is actually very easy for Python, at least on my distro). Compiling Python is not especially fast (around a full minute on my 4-core, 10-year-old machine), although I've experienced much worse in my lifetime. Maybe you can get alternate python versions directly from your distro or a PPA, but not in a way that a cross-distro tool can feasibly automate. On Windows the only realistic option is the official installer.
    - globular-toast 2y ago
forgingahead 2y ago
Python package management has always seemed like crazyland to me. I've settled on Anaconda as I've experimented with all the ML packages over the years, so I'd be interested to learn why uv, and also what/when are good times to use venv/pip/conda/uv/poetry/whatever else has come up. NeutralCrane has a really helpful comment below[0], would love to have a more thorough post on everything! [0]https://news.ycombinator.com/item?id=42677048 https://news.ycombinator.com/item?id=42677048
- agoose77 2y ago
  If you use conda, and can use conda for what you need to do, use conda w/ conda-forge. It has a much better story for libraries with binary dependencies, whereas PyPI (which `uv` uses) is basically full of static libraries that someone else compiled and promises to work. Note, I use PyPI for most of my day-to-day work, so I say this with love!
vietvu 2y ago
I used to have pyenv, asdf or mise to manage python versions (never use conda unless I need DL lib like pytorch). Now just uv is enough.
CGamesPlay 2y ago
I want to like uv, but unfortunately there's some kind of technical distinction between a Python "package manager" and a "build system". Uv doesn't include a "build system", but encourages you to use some other one. The net result is that external dependencies don't build the same as on Poetry, don't work, and uv points the finger at some other dependency. I do hope the situation changes one day. Python packaging is such a mess, but Poetry is good enough and actually works, so I'll stick with it for now.
- zahlman 2y ago
  It's not "some sort of technical distinction". Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. Usually, you can directly make a pre-built wheel, and then an installer like Pip or uv can just unpack that into the environment. If it needs to be build on the user's machine, then you offer an sdist, which specifies its build backend. The installer will act as a build frontend, by downloading and setting up the specified backend and asking it to make a wheel from the sdist, then installing the wheel. Poetry's build backend (`poetry.masonry`) doesn't build your external dependencies unless a) you obtain an sdist and b) the sdist says to use that backend. And in these cases, it doesn't matter what tools you're using. Your installer (which could be Pip, which is not a package manager in any meaningful sense) can work with `poetry.masonry` just fine. If you can give a much more specific, simple, reproducible example of a problem you encountered with external dependencies and uv, I'll be happy to try to help.
  - CGamesPlay 2y ago
    Maybe the docs are misleading? Seems that if I want my package to be installed, I need to pick a build system, regardless of if I am using any native code. https://docs.astral.sh/uv/concepts/projects/init/#packaged-applications https://docs.astral.sh/uv/concepts/projects/init/#packaged-a... > Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. This probably means something to the developers of the package managers and build systems, but to me, as a Python developer who wants to be able to publish a pure Python CLI program to PyPI, it seems like a distinction without a difference.
insane_dreamer 2y ago
been using conda for years with multiple projects each of which has numerous environments (for different versions). fairly large complex environments with coda, tf, jax, etc. has always worked well, and my biggest complaint - the sluggish resolver - largely addressed with mamba resolver. packages not available on conga-forge can be installed into the conda env pip. maybe I'm missing something but it's not clear to me what advantage uv would provide over conda.
- claytonjy 2y ago
  It is very difficult for most conda users to maintain conda environments. They use the same env for nearly all their work, don’t understand the hierarchical nature of conda envs, don’t know which one they’re installing into, install stuff with pip without recording it in their env file, etc. The worst local environment messes i’ve ever seen always involve conda. It can be used effectively, but does not make it easy to do so. uv makes itself harder to misuse
- camel_Snake 2y ago
  I believe pixi, by the same group (astral) is the better comparison to conda. https://pixi.sh/latest/build/getting_started/ https://pixi.sh/latest/build/getting_started/
krick 2y ago
Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even bother typing pip install, PyCharm does it for me. This is of course bad practice. What I would like instead is what PHP's composer does: installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv), automatically freezes the versions, and then it is on git diff to tell me what I did last night, I'll remove a couple of lines from that file, run composer install and it will remove packages not explicitly added to my config from the environment. Does this finally get easy to achieve with uv?
- 8n4vidtmkvmk 2y ago
  I haven't tried it, but I think so? https://docs.astral.sh/uv/concepts/projects/layout/#the-lockfile https://docs.astral.sh/uv/concepts/projects/layout/#the-lock...
- wisty 2y ago
  I'm not an expert, but as far as I can tell UV allows you to do this without feeling so guilty (it handles multiple versions of Python and libraries AFAIK quite well).
- zahlman 2y ago
  >installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv) pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.toml is meant for abstract dependencies, where an installer figures out transitively what's needed to support them and decides on exact versions to install. The current work for specifying a lockfile standard is https://peps.python.org/pep-0751/ https://peps.python.org/pep-0751/ . As someone else pointed out, uv currently already uses a proprietary lockfile, but there has been community interest in trying to standardize this - it just has been hard to find agreement on exactly what it needs to contain. (In the past there have been proposals to expand the `pyproject.toml` spec to include other information that lockfiles often contain for other languages, such as hashes and supply-chain information. Some people are extremely against this, however.) As far as I know, uv isn't going to do things like analyzing your codebase to determine that you no longer need a certain dependency that's currently in your environment and remove it (from the environment, lock file or `pyproject.toml`). You'll still be on the hook for figuring out abstractly what your project needs, and this is important if you want to share your code with others.
tandav 2y ago
I'm waiting for this issue to be done: Add an option to store virtual environments in a centralized location outside projects https://github.com/astral-sh/uv/issues/1495 https://github.com/astral-sh/uv/issues/1495 I have used virtualenvwrapper before and it was very convenient to have all virtual environments stored in one place, like ~/.cache/virtualenvs. The .venv in the project directory is annoying because when you copy folder somewhere you start copying gigabytes of junk. Some tools like rsync can't handle CACHEDIR.TAG (but you can use --exclude .venv)
ErikBjare 2y ago
I really thought this would mention uv script deps (standardized by some PEP) together with a `#!/usr/bin/env -S uv run` shebang line which automatically install the deps on execution. Has been super useful to write single-file tools/scripts which LLMs can understand and run easily.
fire_lake 2y ago
Even better would be if you could specify the dependencies inside of the script. Edit: might be possible now? https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
guru4consulting 2y ago
When using Maven build tool with Java, the downloaded artifacts always have the version number added to prefix (artifact-version.jar).. and that means there can be multiple versions stored in parallel, cached globally and cherry picked without any ambiguity. The first time when I used Node and Python, I was shocked that the version number is not part of any downloaded artifacts. Versioning the dependencies is such a fundamental need and having it part of the artifact file itself seems like a common sense to me. Can anyone please explain why the Python/Node build tools do not follow that?
- mixmastamyk 2y ago
  Version number is part of every wheel and sdist filename.
egeres 2y ago
This is super cool, personally: uv run --python 3.12 --with label-studio label-studio Made my life so much easier

502 points by astronautas 2y ago

instig007 2y ago

wow, they've re-invented a tiny bit of Nix, purely legend!

smallmancontrov 2y ago
A few months ago I saw someone hacking the linker to get mundane package management working in Nix. It was bubbling up to the top of my "to try" list and that bumped it back down. It'll be good eventually, I'm sure.
- instig007 2y ago
  > It'll be good eventually, I'm sure. not with this attitude of getting scared of things by watching someone doing something, for sure
  - smallmancontrov 2y ago
    I have fixed enough (dynamic) linker issues for this lifetime and probably several more. I think I'll let the kids take these. Godspeed.
lucsky 2y ago
That you can use without having 4 PhDs. It's pretty good. You should try it sometime when your done fully ingesting algebraic topology theory or whatever the fuck Nix requires to know just to install figlet.
- 331c8c71 2y ago
  Oh come on, it's not that hard even for packaging stuff (let alone usage). Quite trivial compared to leetcode grind I'd say.
  - amelius 2y ago
    Everybody will reinvent Nix if they are in software engineering long enough ...
    - 331c8c71 2y ago
      If only... Majority will use whatever is shoved up their a## be it docker or anything else.
  - sgarland 2y ago
    You say that, but there seems be a vast chasm between “can solve LC hards” and “can administer an OS,” even though the latter is generally not at all abstract, extremely well-documented, and almost certainly has associated man pages.
- Evidlo 2y ago
  Try flox [0]. It's an imperative frontend for Nix that I've been using. I don't know how to use nix-shell/flakes or whatever it is they do now, but flox makes it easy to just install stuff. [0]: https://flox.dev/ https://flox.dev/
- instig007 2y ago
  > You should try it sometime when your done fully ingesting algebraic topology theory or whatever the fuck Nix requires to know aka how to say that you've never really tried learning Nix without saying it directly.
forrestthewoods 2y ago
Nix people are more annoying than Rust Defense Force. I use Windows, and not WSL. Nix does literally nothing for me.
- instig007 2y ago
  [flagged]
  - forrestthewoods 2y ago
    There’s vastly more Windows devs than you realize. Vastly.

lukax 2y ago

Uv also bundles uvx command so you can run Python scripts without installing them manually: uvx --from 'huggingface_hub[cli]' huggingface-cli

astronautas 2y ago
Neat!
oulipo 2y ago
And there's also the `uv run script.py` where you can have dependencies indicated as comments in the script, see eg https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

tasn 2y ago

OK, I'm convinced. I just installed uv. Thanks for sharing!

smallmancontrov 2y ago
Ditto. This is pretty cool!

retroflexzy 2y ago

uv implements PEP 723. https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... Especially useful if the script has dependencies on packages in private repos.

supakeen 2y ago

The activation of the virtualenv is unnecessary (one can execute pip/python directly from it), and the configuring of your local pyenv interpreter is also unnecessary, it can create a virtual environment with one directly: pyenv virtualenv python3.12 .venv .venv/bin/python -m pip install pandas .venv/bin/python Not quite one command, but a bit more streamlined; I guess.

astronautas 2y ago
Indeed, you're right ;).
BeeOnRope 2y ago
Note that in general calling the venv python directly vs activating the venv are not equivalent. E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.
- meitham 2y ago
  Surely if you want to invoke python you call sys.executable otherwise if your subprocess doesn’t inherit PATH nothing will work with uv or without uv
  - zahlman 2y ago
    In rare cases, programs might also care about the VIRTUAL_ENV environment variable set by the activate script, and activation may also temporarily clear out any existing PYTHONHOME (a rarely used override for the location of the standard library). But yes, in general you can just run the executable directly.
  - BeeOnRope 2y ago
    I don't think that's "sure" at all. For one thing, only Python code directly calling Python has that option in the first place, often there is another layer of indirection, e.g., Python code which executes a shell script, which itself invokes Python, etc. IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.

dang 2y ago

I've replaced the linkbait title with an attempt at saying what the feature is. If there's a more accurate wording, we can change it again.

astronautas 2y ago
uh, thanks I guess.
- astronautas 2y ago
  How about "A UV feature that intrigues me most"?
  - airstrike 2y ago
    Still clickbait if you don't say what the feature is.
  - minimaxir 2y ago
    That's still clickbait, although less tropey. The common definition of clickbait is intentionally omitting information that incentives the user to click.
- dang 2y ago
  It's just standard practice here. See https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
  - astronautas 2y ago
    see my reply above
zanie 2y ago
I don't feel strongly, but as a uv author, I found "local dependencies" misleading. It's more like "uv's killer feature is making ad-hoc environments easy". When we talk about local dependencies in the Python packaging ecosystem, it's usually adding some package on your file system to your environment. The existing title made me think this would be about the `[tool.uv.sources]` feature. Really, it's about how we create environments on-demand and make it trivial to add packages to your environment or try other Python versions without mutating state.

nharada 2y ago

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you could use conda too"

poincaredisk 2y ago
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
- mplewis 2y ago
  Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
  - aidos 2y ago
    I’ve always worked around that by having a requirements.base.txt and a requirements.txt for the locked versions. Obviously pip doesn’t do that for you but it’s not hard to manage yourself. Having said that, I’m going to give uv a shot because I hear so many good things about it.
    - mikepurvis 2y ago
      I’m grouchy because I finally got religion on poetry a few years ago, but the hype on uv is good enough that I’ll have to give it a shot.
      - kstrauser 2y ago
        I freaking love Poetry. It was a huge breath of fresh air after years of pip and a short detour with Pipenv. If uv stopped existing I’d go back to Poetry. But having tasted the sweet nectar of uv goodness, I’m onboard the bandwagon.

faizshah 2y ago

I love this, the biggest problem I have right now with python scripts is distributing my single file utility scripts (random ops scripts). I wish there was a way to either shebang something like this or build a wheel that has the full venv inside.

delusional 2y ago
You are in luck https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
easton 2y ago
There’s a shebang now. as of PEP 722 you can declare dependencies in a comment at the top of a single file script that a package manager can choose to read and resolve. uv has support for it: https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies https://docs.astral.sh/uv/guides/scripts/#running-a-script-w... (which only helps if your team is all in on uv, but maybe they are)
- eesmith 2y ago
  PEP 722 was rejected. You are thinking of PEP 723, which was very similar to 722 in goals. https://discuss.python.org/t/pep-722-723-decision/36763 https://discuss.python.org/t/pep-722-723-decision/36763 contains the reasoning for accepting 723 and rejecting 722.
- miohtama 2y ago
  Do other package managers support this yet?
  - zahlman 2y ago
    Pipx isn't in any meaningful sense a package manager (although it can manage environments to a limited extent), but the `pipx run` command supports this PEP as of version 1.4.2.
- amelius 2y ago

stevage 2y ago

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

mdaniel 2y ago
Caveat: I'm a node outsider, only forced to interact with it But there are a shocking number of install instructions that offer $(npm i -g) and if one is using Homebrew or nvm or a similar "user writable" node distribution, it won't prompt for sudo password and will cheerfully mangle the "origin" node_modules So, it's the same story as with python: yes, but only if the user is disciplined Now ruby drives me fucking bananas because it doesn't seem to have either concept: virtualenvs nor ./ruby_modules
- andrewmcdonough 2y ago
  Ruby has a number of solutions for this - rvm (the oldest, but less popular these days), rbenv (probably the most popular), chruby/gem_home (lightweight) or asdf (my personal choice as I can use the same tool for lots of languages). All of those tools install to locations that shouldn't need root.
  - mdaniel 2y ago
    Yes, I am aware of all of those, although I couldn't offhand tell anyone the difference in tradeoffs between them. But I consider having to install a fresh copy of the whole distribution a grave antipattern. I'm aware that nvm and pyenv default to it and I don't like that I did notice how Homebrew sets env GEM_HOME=<Cellar>/libexec GEM_PATH=<Cellar>/libexec (e.g. <https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f7e7cca264f406a370b3fb967ee4/Formula/f/fastlane.rb#L35-L36 https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f...>) but, similar to my node experience, since I am a ruby outsider I don't totally grok what isolation that provides
- MrJohz 2y ago

emiller88 2y ago

There's so many more! 1. `uvx --from git+https://github.com/httpie/cli https://github.com/httpie/cli httpie` 2. https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/ https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/ uv in a shebang

throwup238 2y ago
The uv shebang is definitely the killer feature for me, especially with so much of the AI ecosystem tied up in Python. Before, writing Python scripts was a lot more painful requiring either a global scripts venv and shell scripts to bootstrap them, or a venv per script. I’m sure it was already possible with shebangs and venv before, but uv really brings the whole experience together for me so I can write python scripts as freely as bash ones.
FergusArgyll 2y ago
Yes! since that Simon Willison article, I've slowly been easing all my scripts into just using a uv shebang, and it rocks! I've deleted all sorts of .venvs and whatnot. really useful
dingdingdang 2y ago
Super neat re Willison article.. would something like this work under powershell though?!

curiousgal 2y ago

uv has does not (nor do they plan to add) support for conda, and that is a deal-breaker.

throwaway314155 2y ago
That doesn't make sense, respectfully.
PaulHoule 2y ago
I can't see why anyone is using Conda in 2025. In 2018, yeah, pip (now uv) was hard and you could get a "just works" experience installing Tensorflow + NVIDIA on Conda. In 2023 it was the other way around and it still is.
- curiousgal 2y ago
  Well, when you're building python packages that have non python dependencies and a big chunk of your users are on Windows, conda is the only option, even in 2025 :) Examples include, quant libraries, in-house APIs/tools, etc.
  - amelius 2y ago
    Conda worked for me in the past, but at some point I was getting inexplicable segfaults from Python scripts. I switched back to just pip and everything worked fine again. And installation was much faster.
    - PaulHoule 2y ago
      That was basically my experience. At one time conda made my life easier, eventually it made it impossible.
  - PaulHoule 2y ago
    Circa 2018, I figured out how to pack up the CUDA libraries inside conda for Windows so I could have different conda environments with different versions of CUDA which was essential back then because if you had a model that was written w/ a certain version of Tensorflow you had to have a matching CUDA and if you used NVIDIA's we-need-your-email-address installers you could only have one version of CUDA installed at a time. Worked great except for conda making the terrible mistake of compressing package files with bzip2 which took forever to decompress for huge packages. I see no reason you can't install any kind of non-Python thing that a Python system wants with uv because a wheel is just a ZIP file, so long as it doesn't need to be installed in a particular place you can just unpack it and go.

minimaxir 2y ago

What would be interesting is if you could do something similar for IPython/Jupyter Notebooks: while front-ends like JupyterLab and VS Code Notebooks do let you select a .venv if present in the workspace, it's annoying to have to set one up and build one for every project.

mirekrusin 2y ago
https://github.com/manzt/juv https://github.com/manzt/juv

riwsky 2y ago

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

aeurielesn 2y ago
I don't understand how things like this get approved into PEPs.
- zanie 2y ago
  As in, you think this shouldn't be possible or you think it should be written differently?
- Karupan 2y ago
  Seems like a great way to write self documenting code which can be optionally used by your python runtime.
- linsomniac 2y ago
  I don't think this IS a PEP, I believe it is simply something the uv tool supports and as far as Python is concerned it is just a comment.
  - mkl 2y ago
    https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
    - linsomniac 2y ago
      Thank you for the pointer, I had searched for it but couldn't find it. (edit: Glad I spent the downvotes to get educated :-)
  - zanie 2y ago

laidoffamazon 2y ago

I honestly really hate the venv ergonomics but uv does still depend on it as the golden path if you don’t use the —with flags (in my understanding). Is there a way to do a clean break with just the new —script inline dependencies, or is that wrong/suboptimal?

zanie 2y ago
You can definitely do that — it's just sub-optimal when you have multiple files that share dependencies.

aizk 2y ago

one useful UV alias I use is uvsys='uv pip install --system' So I can just do uv {package} for a quick and dirty global install. I'm so used to pip install being global by default just making this shorthand makes things a bit easier.

claytonjy 2y ago
this sounds like it’s asking for trouble! very easy to mess up your whole system i would highly recommend only using —-system in a docker container or similar

amelius 2y ago

Sometimes, only a specific wheel is available (e.g. on Nvidia's Jetson platform where versions are dictated by the vendor). Can uv work with that?

valcron1000 2y ago

Can you also specify which version of pandas to use?

zanie 2y ago
Of course! uv run -q --with pandas==2.1.4 python -c "import pandas; print(pandas.__version__)" 2.1.4

secondcoming 2y ago

[flagged]

zahlman 2y ago
>you need a virtual environment for some reason You have always needed on, practically speaking. Python isn't designed to have multiple versions of the same library in the same runtime environment. A virtual environment is just a separate place to put the packages you need for the current project, so that they're isolated from other packages, and thus you don't get version conflicts. This includes the system packages. If you want to play with, say, the latest version of Requests, and you try sudo installing that in a system environment, and it happens that the latest version of Requests breaks Apt (which is written in Python), you're in for a bad time. The new warning is because even user-level installations can mess with system scripts, when those scripts are run without sudo. Also, Apt has no real way to know about or understand anything you do with Pip, so that interferes with Apt's actual package management. >installing packages [with] sudo doesn't make them available to other users If you use sudo to install packages for the system Python, then yes they absolutely are available to all users. But you don't see them in virtual environments by default (you can change this) because the default is to ignore the system installation's `site-packages` completely (including user-level installations). > on ubuntu it seems pip has been replaced with 'python-*' debian packages None of this is new, and it doesn't even remotely "replace" Pip. You're just facing a little more pressure to actually use the system package manager when installing packages for your system, since that can actually manage packages, and integrate them with the rest of your system (the non-Python parts). The Debian packages are specifically vetted and tested for this purpose and may include Canonical's own patches that you won't get from PyPI. On the other hand, PyPI provides vastly more different packages. When you install in a virtual environment, you'll generally use Pip to do it (unless you use uv etc.). Because the environment is specifically created to be isolated from your system, so that Apt doesn't have to care. Please see https://stackoverflow.com/questions/75608323 https://stackoverflow.com/questions/75608323 for details. It wasn't a snap decision; see https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/10302 https://discuss.python.org/t/pep-668-marking-python-base-env... for context. Arch implements analogous protections, too, for the same reasons (https://www.youtube.com/watch?v=35PQrzG0rG4 https://www.youtube.com/watch?v=35PQrzG0rG4). I recall Fedora having similar plans but I didn't hear about it being implemented yet.

mgd020 2y ago

Whats the point if you have other binary dependencies? Use Nix for Python version as well as other bin deps, and virtualenv + pip-tools for correct package dependency resolution. Waiting 4s for pip-tools instead of 1ms for uv doesn't change much if you only run it once a month.

sonium 2y ago

But I still need pip to install uv, right? Or download it using a one-liner alternatively.

philomath_mn 2y ago
You can install it in several ways without pip, easiest is standalone installer (which can upgrade itself) https://docs.astral.sh/uv/getting-started/installation/ https://docs.astral.sh/uv/getting-started/installation/
dontdieych 2y ago
cargo install

m3kw9 2y ago

That’s like a killer app type feature. However it says adhoc so you probably can’t get back to that setup easily

crispyambulance 2y ago

I do like uv and hope to try it soon but I don't get the point of the article. Pyenv + poetry already gives you ability to "pull in local dependencies". Yes, you have to create a virtual environment and it's not "ad-hoc". But if you're going to pull in a bunch of libraries, WHY would you want to invoke python and all your work dependencies on a one liner? Isn't it much better and easier to just spell-out the dependencies in a pyproject.toml? How "ad-hoc" are we talking here?

wiseowise 2y ago
Yes! I love verbosity. It gives me job security. I’m tired of these tools making my job easier. Previously I could allocate a whole week to setup initial scaffold for the project. Also more tools - more failure points, so I can flex on stupid juniors how smart I am. Now I can’t even go to pee with how fast and easy this freaking uv is. WTF.
- crispyambulance 2y ago
  Well I guess I am not smart enough to dump multiple dependencies + python, densely, on one line to spin everything up so I can do “ad-hoc” computing without just spelling them out in a file. Sorry, but that just isn’t a killer feature for me and it doesn’t seem like a big deal anyway. I do like the idea of getting rid of pyenv though. And since poetry has failed to become as widespread as I hoped, maybe uv has a better shot?

misiek08 2y ago

Small misorder in the „right route” - you should first activate the virtual environment just created and then install pandas.

greatgib 2y ago

Ridiculous post: The author says that a normal route would be: - Take the proper route: - Create a virtual environment - pip install pandas - Activate the virtual environment - Run python Basically, out of the box, when you create an virtual it is immediately activated. And you would obviously need to have it activated before doing a pip install... In addition, in my opinion this is the thing that would sucks about UV to have different functions being tied to a single tool execution. It is a breeze to be able to activate a venv, and be done with it, being able to run multiple times your program in one go, even with crashes, being able to install more dependencies, test it in REPL, ...

hamandcheese 2y ago
You can still use traditional venvs with UV though, if you want.
- krick 2y ago
  Uh, but then you don't really need uv, right?
  - hamandcheese 2y ago
    No, but it is insanely faster than pip.
astronautas 2y ago
Hey, I actually made a silly mistake in my post, indeed you first activate the environment and then install stuff in it. Fixed! I disagree though it is activated immediately, or at least to me with venv I always have to activate it explicitly.

cyrialize 2y ago

For anyone that used rye, it's worth noting that the creator of rye recommends using uv. Also, rye is going to be continually updated to just interface with uv until rye can be entirely replaced by uv.

andelink 2y ago
I believe they are from the same author, Charlie Marsh / Astral
- BiteCode_dev 2y ago
  no armin created rye then gave it to astral

wruza 2y ago

Why can’t python just adopt something like yarn/pnpm + and effing stop patch-copying its binaries into a specific path? And pick up site_packages from where it left it last time? Wtf. How hard it is to just pick python-modules directory and python-project.json and sync it into correctness by symlink/mklink-inf missing folders from a package cache in there in a few seconds? Every time when I have to reorganize or upgrade my AI repos, it’s yet another 50GB writes to my poor ssd. Half of it is torch, another half auto-downloaded models that I cannot stop because they become “downloaded” and you never know how to resume it back or even find where they are cause python logging culture is just barbaric.

bityard 2y ago

I usually stay away far FAR from shiny new tools but I've been experimenting with uv and I really like it. I'm a bit bummed that it's not written in Python but other than that, it does what it says on the tin. I never liked pyenv because I really don't see the point/benefit building every new version of Python you want to use. There's a reason I don't run Gentoo or Arch anymore. I'm very happy that uv grabs pre-compiled binaries and just uses those. So far I have used it to replace poetry (which is great btw) in one of my projects. It was pretty straightforward, but the project was also fairly trivial/typical. I can't fully replace pipx with it because 'uv tool' currently assumes every Python package only has one executable. Lots of things I work with have multiple, such as Ansible and Jupyterlab. There's a bug open about it and the workarounds are not terrible, but it'd be nice if they are able to fix that soon.

meitham 2y ago
uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/ https://gregoryszorc.com/docs/python-build-standalone/main/
- zahlman 2y ago
  >that very same project says this is compiled for portability over performance Realistically, the options on Linux are the uv way, the pyenv way (download and compile on demand, making sure users have compile-time dependencies installed as part of installing your tool), and letting users download and compile it themself (which is actually very easy for Python, at least on my distro). Compiling Python is not especially fast (around a full minute on my 4-core, 10-year-old machine), although I've experienced much worse in my lifetime. Maybe you can get alternate python versions directly from your distro or a PPA, but not in a way that a cross-distro tool can feasibly automate. On Windows the only realistic option is the official installer.
  - globular-toast 2y ago

forgingahead 2y ago

Python package management has always seemed like crazyland to me. I've settled on Anaconda as I've experimented with all the ML packages over the years, so I'd be interested to learn why uv, and also what/when are good times to use venv/pip/conda/uv/poetry/whatever else has come up. NeutralCrane has a really helpful comment below[0], would love to have a more thorough post on everything! [0]https://news.ycombinator.com/item?id=42677048 https://news.ycombinator.com/item?id=42677048

agoose77 2y ago
If you use conda, and can use conda for what you need to do, use conda w/ conda-forge. It has a much better story for libraries with binary dependencies, whereas PyPI (which `uv` uses) is basically full of static libraries that someone else compiled and promises to work. Note, I use PyPI for most of my day-to-day work, so I say this with love!

vietvu 2y ago

I used to have pyenv, asdf or mise to manage python versions (never use conda unless I need DL lib like pytorch). Now just uv is enough.

CGamesPlay 2y ago

I want to like uv, but unfortunately there's some kind of technical distinction between a Python "package manager" and a "build system". Uv doesn't include a "build system", but encourages you to use some other one. The net result is that external dependencies don't build the same as on Poetry, don't work, and uv points the finger at some other dependency. I do hope the situation changes one day. Python packaging is such a mess, but Poetry is good enough and actually works, so I'll stick with it for now.

zahlman 2y ago
It's not "some sort of technical distinction". Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. Usually, you can directly make a pre-built wheel, and then an installer like Pip or uv can just unpack that into the environment. If it needs to be build on the user's machine, then you offer an sdist, which specifies its build backend. The installer will act as a build frontend, by downloading and setting up the specified backend and asking it to make a wheel from the sdist, then installing the wheel. Poetry's build backend (`poetry.masonry`) doesn't build your external dependencies unless a) you obtain an sdist and b) the sdist says to use that backend. And in these cases, it doesn't matter what tools you're using. Your installer (which could be Pip, which is not a package manager in any meaningful sense) can work with `poetry.masonry` just fine. If you can give a much more specific, simple, reproducible example of a problem you encountered with external dependencies and uv, I'll be happy to try to help.
- CGamesPlay 2y ago
  Maybe the docs are misleading? Seems that if I want my package to be installed, I need to pick a build system, regardless of if I am using any native code. https://docs.astral.sh/uv/concepts/projects/init/#packaged-applications https://docs.astral.sh/uv/concepts/projects/init/#packaged-a... > Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. This probably means something to the developers of the package managers and build systems, but to me, as a Python developer who wants to be able to publish a pure Python CLI program to PyPI, it seems like a distinction without a difference.

insane_dreamer 2y ago

been using conda for years with multiple projects each of which has numerous environments (for different versions). fairly large complex environments with coda, tf, jax, etc. has always worked well, and my biggest complaint - the sluggish resolver - largely addressed with mamba resolver. packages not available on conga-forge can be installed into the conda env pip. maybe I'm missing something but it's not clear to me what advantage uv would provide over conda.

claytonjy 2y ago
It is very difficult for most conda users to maintain conda environments. They use the same env for nearly all their work, don’t understand the hierarchical nature of conda envs, don’t know which one they’re installing into, install stuff with pip without recording it in their env file, etc. The worst local environment messes i’ve ever seen always involve conda. It can be used effectively, but does not make it easy to do so. uv makes itself harder to misuse
camel_Snake 2y ago
I believe pixi, by the same group (astral) is the better comparison to conda. https://pixi.sh/latest/build/getting_started/ https://pixi.sh/latest/build/getting_started/

krick 2y ago

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even bother typing pip install, PyCharm does it for me. This is of course bad practice. What I would like instead is what PHP's composer does: installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv), automatically freezes the versions, and then it is on git diff to tell me what I did last night, I'll remove a couple of lines from that file, run composer install and it will remove packages not explicitly added to my config from the environment. Does this finally get easy to achieve with uv?

8n4vidtmkvmk 2y ago
I haven't tried it, but I think so? https://docs.astral.sh/uv/concepts/projects/layout/#the-lockfile https://docs.astral.sh/uv/concepts/projects/layout/#the-lock...
wisty 2y ago
I'm not an expert, but as far as I can tell UV allows you to do this without feeling so guilty (it handles multiple versions of Python and libraries AFAIK quite well).
zahlman 2y ago
>installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv) pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.toml is meant for abstract dependencies, where an installer figures out transitively what's needed to support them and decides on exact versions to install. The current work for specifying a lockfile standard is https://peps.python.org/pep-0751/ https://peps.python.org/pep-0751/ . As someone else pointed out, uv currently already uses a proprietary lockfile, but there has been community interest in trying to standardize this - it just has been hard to find agreement on exactly what it needs to contain. (In the past there have been proposals to expand the `pyproject.toml` spec to include other information that lockfiles often contain for other languages, such as hashes and supply-chain information. Some people are extremely against this, however.) As far as I know, uv isn't going to do things like analyzing your codebase to determine that you no longer need a certain dependency that's currently in your environment and remove it (from the environment, lock file or `pyproject.toml`). You'll still be on the hook for figuring out abstractly what your project needs, and this is important if you want to share your code with others.

tandav 2y ago

I'm waiting for this issue to be done: Add an option to store virtual environments in a centralized location outside projects https://github.com/astral-sh/uv/issues/1495 https://github.com/astral-sh/uv/issues/1495 I have used virtualenvwrapper before and it was very convenient to have all virtual environments stored in one place, like ~/.cache/virtualenvs. The .venv in the project directory is annoying because when you copy folder somewhere you start copying gigabytes of junk. Some tools like rsync can't handle CACHEDIR.TAG (but you can use --exclude .venv)

ErikBjare 2y ago

I really thought this would mention uv script deps (standardized by some PEP) together with a `#!/usr/bin/env -S uv run` shebang line which automatically install the deps on execution. Has been super useful to write single-file tools/scripts which LLMs can understand and run easily.

fire_lake 2y ago

Even better would be if you could specify the dependencies inside of the script. Edit: might be possible now? https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

guru4consulting 2y ago

When using Maven build tool with Java, the downloaded artifacts always have the version number added to prefix (artifact-version.jar).. and that means there can be multiple versions stored in parallel, cached globally and cherry picked without any ambiguity. The first time when I used Node and Python, I was shocked that the version number is not part of any downloaded artifacts. Versioning the dependencies is such a fundamental need and having it part of the artifact file itself seems like a common sense to me. Can anyone please explain why the Python/Node build tools do not follow that?

mixmastamyk 2y ago
Version number is part of every wheel and sdist filename.

egeres 2y ago

This is super cool, personally: uv run --python 3.12 --with label-studio label-studio Made my life so much easier