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.
Uv's killer feature is making ad-hoc environments easy
241–250 of 428 posts
Re: Uv's killer feature is making ad-hoc environments easy
#242Earlier quoted context omitted.
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore. The dependency management and installation is lightning quick. It deals with all of the python versioning and I think a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run Your script code would like: #!/usr/bin/env -S uv run --scri…
>Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore.
I might just blow your mind here:
$ time python -m venv with-pip
real 0m3.248s
user 0m3.016s
sys 0m0.219s
$ time python -m venv --without-pip without-pip
real 0m0.054s
user 0m0.046s
sys 0m0.009s
$ source without-pip/bin/activate
(without-pip) $ ~/.local/bin/pip --python `which python` install package-installation-test
Collecting package-installation-test
Using cached package_installation_test-1.0.0-py3-none-any.whl.metadata (3.1 kB)
Using cached package_installation_test-1.0.0-py3-none-any.whl (3.1 kB)
Installing collected packages: package-installation-test
Successfully installed package-installation-test-1.0.0
> a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run
Yes, Uv implements PEP 723 "Inline Script Metadata" (https://peps.python.org/pep-0723/) - originally the idea of Paul Moore from the Pip dev team, whose competing PEP 722 lost out (see https://discuss.python.org/t/_/29905). He's been talking about a feature like this for quite a while, although I can't easily find the older discussion. He seems to consider it out of scope for Pip, but it's also available in Pipx as of version 1.4.2 (https://pipx.pypa.io/stable/CHANGELOG/).
> The first run is a bit slower due to downloads and etc, but the second and subsequent runs are a bunch of internal symlink shuffling.
Part of why Pip is slow at this is because it insists on checking PyPI for newer versions even if it has something cached, and because its internal cache is designed to simulate an Internet connection and go through all the usual metadata parsing etc. instead of just storing the wheels directly. But it's also just slow at actually installing packages when it already has the wheel.
In principle, nothing prevents a Python program from doing caching sensibly and from shuffling symlinks around.
Re: Uv's killer feature is making ad-hoc environments easy
#243Earlier quoted context omitted.
pip's resolving algorithm is not sound. If your Python projects are really simple it seems to work but as your projects get more complex the failure rate creeps up over time. You might pip install something and have it fail and then go back to zero and restart and have it work but at some point that will fail. conda has a correct resolving algorithm but the packages are out of date and add about as many quality probl…
Ugh, I hate writing this but that's where docker and microservices comes to the rescue. It's a pain in the butt and inefficient to run but if you don't care about the overhead (and if you do care, why are you still using Python?), it works.
Yes, another sound reason to use microservices. /s
Re: Uv's killer feature is making ad-hoc environments easy
#244I 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…
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
I was in your boat too. Been using Python since 2000 and pretty satisfied with venv and pip.
However, the speed alone is reason enough to switch. Try it once and you will be sold.
Re: Uv's killer feature is making ad-hoc environments easy
#245Earlier quoted context omitted.
Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…
Oh wow, it actually can handle the Python executable? I didn't know that, that's great! Although it's in the article as well, it didn't click until you said it, thanks!
I would avoid using this feature! It downloads a compiled portable python binary from some random github project not from PSF. That very same github project recommends against using their binary as the compilation flags is set for portability against performance. See https://gregoryszorc.com/docs/python-build-standalone/main/
Re: Uv's killer feature is making ad-hoc environments easy
#246Earlier quoted context omitted.
I don't understand how things like this get approved into PEPs.
with that expected use case of uv script run command it effectively makes those comments executable python's wheels are falling off at an ever faster and faster rate
Because of a feature that solves the problem of one off scripts being difficult the moment you need a 3rd party library?
A more Pythonic way of doing this might be __pyproject__ bit that has the tiiiiny snag of needing to execute the file to figure out its deps. I would have loved if __name__ == "pyproject" but while neat and tidy it is admittedly super confusing for beginners, has a "react hooks" style gotcha where to can't use any deps in that block, and you can't use top level imports. The comment was really the easiest way.
Re: Uv's killer feature is making ad-hoc environments easy
#247Earlier quoted context omitted.
I still don't understand why people want separate tooling to "handle the Python executable". All you need to do is have one base installation of each version you want, and then make your venv by running the standard library venv for that Python (e.g. `python3.x -m venv .venv`).
> All you need to do is have one base installation of each version you want Because of this ^
But any tool you use for the task would do that anyway (or set them up temporarily and throw them away). Python on Windows has a standard Windows-friendly installer, and compiling from source on Linux is the standard few calls to `./configure` and `make` that you'd have with anything else; it runs quite smoothly and you only have to do it once.
Re: Uv's killer feature is making ad-hoc environments easy
#248Earlier quoted context omitted.
> pip doesn't resolve dependencies of dependencies. This is simply incorrect. In fact the reason it gets stuck on resolution sometimes is exactly because it resolved transitive dependencies and found that they were mutually incompatible. Here's an example which will also help illustrate the rest of my reply. I make a venv for Python 3.8, and set up a new project with a deliberately poorly-thought-out pyproject.toml:…
> Well, sure; Pip can't respect a version pin that doesn't exist anywhere in your project. If the specific version of Pandas you want says that it's okay with a range of Numpy versions, then of course Pip has freedom to choose one of those versions. If that matters, you explicitly specify it Nearly every other language solves this better than this. What your suggesting breaks down on large projects.
>Nearly every other language solves this better than this.
"Nearly every other language" determines the exact version of a library to use for you, when multiple versions would work, without you providing any input with which to make the decision?
If you mean "I have had a more pleasant UX with the equivalent tasks in several other programming languages", that's justifiable and common, but not at all the same.
>What your suggesting breaks down on large projects.
Pinned transitive dependencies are the only meaningful data in a lockfile, unless you have to explicitly protect against supply chain attacks (i.e. use a private package source and/or verify hashes).
Re: Uv's killer feature is making ad-hoc environments easy
#249Earlier quoted context omitted.
> All you need to do is have one base installation of each version you want Because of this ^
But any tool you use for the task would do that anyway (or set them up temporarily and throw them away). Python on Windows has a standard Windows-friendly installer, and compiling from source on Linux is the standard few calls to `./configure` and `make` that you'd have with anything else; it runs quite smoothly and you only have to do it once.
I need to tell you a secret...
I'm a long-life Linux user (since mandrake!)
Also, I don't have a c compiler installed.
Re: Uv's killer feature is making ad-hoc environments easy
#250I 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…
This: > I haven't felt like it's a minor improvement on what I'm using means that this: > I'd love if we standardized on it as a community as the de facto default …probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it is…
As it happens, the Python REPL was just replaced a few months ago!
…Not with IPython. But with an implementation written in Python instead of C, originating from the PyPy project, that supports fancier features like multi-line editing and syntax highlighting. See PEP 762.
I was apprehensive when I heard about it, but then I had the chance to use it and it was a very nice experience.