undefined | Better HN

0 pointsppierald1y ago0 comments

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 <scriptname>

Your script code would like:

#!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "...", # "..." # ] # ///

Then uv will make a new venv, install the dependencies, and execute the script faster than you think. 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.

It is really interesting. You should at least take a look at a YT or something. I think you will be impressed.

Good luck!

0 comments

zahlman1y ago

>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

The thing that actually takes time is installing Pip into the venv. I already have local demonstrations that this installation can be an order of magnitude faster in native Python. But it's also completely unnecessary to do that:

  $ 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

I have wrappers for this, of course (and I'm explicitly showing the path to a separate Pip that's already on my path for demonstration purposes).

> a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run <scriptname>

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.

matsemann1y ago

It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works.

I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disregard it.

I'm a python programmer at my job, and I've hated the tooling for years. Uv is the first time I actually like working with python.

zahlman1y ago

None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do.

The problems you're describing, or seeing solved with uv, don't seem to be about a problem with the design of virtual environments. (Uv still uses them.) They're about not having the paradigm of making a venv transiently, as part of the code invocation; or they're about not having a built-in automation of a common sequence of steps. But you can do that just as well with a couple lines of Bash.

I'm not writing any of this to praise the standard tooling. I'm doing it because the criticisms I see most commonly are inaccurate. In particular, I'm doing it to push back against the idea that a non-Python language is required to make functional Python tooling. There isn't a good conceptual reason for that.

2 more replies

j / k navigate · click thread line to collapse

0 comments

zahlman1y ago

>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

I have wrappers for this, of course (and I'm explicitly showing the path to a separate Pip that's already on my path for demonstration purposes).

> a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run <scriptname>

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

In principle, nothing prevents a Python program from doing caching sensibly and from shuffling symlinks around.

matsemann1y ago

I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disregard it.

I'm a python programmer at my job, and I've hated the tooling for years. Uv is the first time I actually like working with python.

zahlman1y ago

None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do.

2 more replies

j / k navigate · click thread line to collapse