uv

Fun fact! The original request to add a concurrency variable in uv was requested by me because, among other things, I wanted to measure the difference between uv and pip: https://github.com/astral-sh/uv/issues/3311 I'm not really following this performance discussion as I think it's gone off the rails.

We didn't compare to pip at the time, but it saved a lot of absolute time for us as reported in the benchmarks from the pull request (https://github.com/astral-sh/uv/pull/789) it improved a boto3 case by 3x (30s to 10s) and our "standard" solve benchmark by 2x. It's plausible some of those gains have been reduced by other optimizations in our solver since then though. But this was just one example optimization, we do other low-level things, like zero-copy deserialization from our cache. The point is not that we do specific things, but that we have more levers to pull to improve performance. It's great to see all the improvements happening in pip performance regardless :)

(I work on uv) > The only advantage of uv is to have support for parallel async extraction. This isn't true, the biggest speed ups are for the warm cases where we've already unpacked the files into the cache, as notatallshaw mentions above. We can also make low-level optimizations during resolution, e.g., in version parsing, that are not possible in pure Python code. > If pip extracted multiple files/wheels in parallel without being blocked by the GIL, pip could easily match or outcompete uv. I'm a bit confused by these claims about the GIL? The expensive IO operations release the GIL. > When the user edits one file, all files are modified simultaneously This is why we default to reflinks or copy-on-write semantics when creating environments, not all file systems support it but it's becoming more common. > Hypothetically, a simple dedupli

I have never gotten the speed argument either. Yes it's noticeably faster - but in all my projects it's 1s vs 0.1s, not enough to make a meaningful difference. Even in their benchmarks, the worst number they ever give for pip is 7s [1] (and those numbers are 2+ years old, with python's improvements pip should be doing a little better now). I just can't say I've ever cared about installing dependencies, something you do once, taking 7s longer. Nor do I care how long CI takes, it running in the background is the point. The one use I can give it is for running scripts with inline dependencies. I have found it a noticeable improvement over pipx there. But that's more due to needing to parse dependencies every single launch, if it's something I use regularly I end up just installing them normally instead, and it's faster than either. [1] https

These are the Python distributions we use in uv (https://github.com/astral-sh/uv), i.e., when you install Python with uv, you're installing from python-build-standalone. (Same goes for many of the other tools that can install Python for you, like pipx, Hatch, Poetry, Bazel, etc.) Most of our engineering time on the project over the past ~year and a half has been split into three buckets: 1. Keeping up with upstream CPython. (We're also hoping to upstream as much of this work as we can into CPython itself.) 2. Fixing any / all of the known "quirks" vis-a-vis CPython. 3. Making these distributions as fast as (or faster than) any other CPython distribution. If you're interested, I wrote a bit about the why / how here when we took over maintenance of the project: https://x.com/charliermarsh/status/1864050698574311561

podman's been great for me on macOS for testing stuff quick; which earlier used to need a whole limactl[3]/virt thing. you can set it up with qemu-user-static for --platform linux/amd64; i don't remember which i exactly used, or if official docs have been updated for it but looked something like [1] there is one sneaky bug in qemu that breaks uv [2] for cross-platform targets so i keep having to fall back to lima for that, but great otherwise. [1]: https://www.itix.fr/blog/qemu-user-static-with-podman/ [2]: https://github.com/astral-sh/uv/issues/16024 , https://gitlab.com/qemu-project/qemu/-/work_items/3130 [3]: https://lima-vm.io/

burntsushi also works in this company (or worked?). he is actually a developer of uv (or was a couple years ago?) https://github.com/astral-sh/uv/graphs/contributors?from=9%2...

For Python, `uv` [1] delivers a similar experience. Faster dependencies. Better dependency management with `pyproject.toml`. Just use it with `uv run` or `uvx`. [1] https://github.com/astral-sh/uv

Here's where that feature was (and is still being) discussed in the uv repo: https://github.com/astral-sh/uv/issues/1495 It's been open for two years but it looks like there's a PR in active development for it right now: https://github.com/astral-sh/uv/pull/18214

The telemetry they removed here isn't unique to uv, and it's not being sent back to Astral. Here's the equivalent code in pip itself: https://github.com/pypa/pip/blob/59555f49a0916c6459755d7686a... It's providing platform information to PyPI to help track which operating systems and platforms are being used by different packages. The result is useful graphs like these: https://pypistats.org/packages/sqlite-utils and https://pepy.tech/projects/sqlite-utils?timeRange=threeMonth... The field that guesses if something is running in a CI environment is particularly useful, because it helps package authors tell if their package is genuinely popular or if it's just being installed in CI thousands of times a day by one heavy user who doesn't cache their requirements. Honestly, stripping this data and then implying that it was collected by Astral/