charliermarsh

Making things faster is much easier than making things smaller. I'm sure we can win back a 4% slowdown elsewhere since we have so many more levers to pull from.

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

> Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice.

We ignore upper bounds because it leads to a better solve. You can read my comment here: https://news.ycombinator.com/item?id=46464453. There's significant discussion about this, e.g., here: https://discuss.python.org/t/requires-python-upper-limits/12....

> Ambiguity detection is important.

I think you're misunderstanding why we do this: it's a security feature. pip's design is inherently vulnerable to dependency confusion attacks, since packages of the same name across indexes are considered equally trusted by pip. You can look up the torchtriton attack to learn more.

> Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.

I think you're misinformed. We support all of these features: system- and per-user configuration files, environment variables, etc. We just don't read _pip's_ configuration file, which is intended for pip, not uv.

I'm not super familiar with Bundler's architecture but I think the most impactful thing would be adopting uv's cache design, which is a big part of what makes uv so fast and should be replicable in other languages and ecosystems.

> Ignoring requires-python upper bounds. When a package says it requires python<4.0, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong.

I don't think that ignoring upper bounds has a significant impact on uv's performance. We do this for a totally different reason, which is that it leads to better solves. For example, if you say your project requires Python 3.8 or later, but some dependency said it works for ">=3.8,<4", then suddenly your project isn't installable on Python 4, and you'd be implicitly required to put a "<4" bound on your own project. uv solves for all of your supported Python versions, not a single version, so discounting the upper bounds doesn't actually save us any time in the solve.

(See, e.g. https://discuss.python.org/t/requires-python-upper-limits/12....)

If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.

We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!

The PEP includes the ability to enable (or disable) lazy imports globally via a command-line flag or environment variable, in addition to the import syntax.

Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966.... If I recall correctly, lazy imports are a feature supported in Cinder, Meta's version of CPython, and the PEP was driven by folks that worked on Cinder. Last time, a lot of the discussion centered around questions like: Should this be opt-in or opt-out? At what level? Should it be a build-flag for CPython itself? Etc. The linked post suggests that the Steering Council ultimately rejected it because of the complexity it would introduce to have two divergent "modes" of importing.

I hope this proposal succeeds. I would love to use this feature.

All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff` as a linter and `black` as a formatter, or `ruff` for both, or whatever. Here, similarly, you can use `uv` with `ruff`, or bring your own formatter. It's intentional for us that you can use the pieces that you want, and interoperate with other tools. But it's also intentional that we want using our tools _together_ to be a great experience. I think we can achieve both of these things. Or, at least, we're going to try.

We already develop a formatter: Ruff (https://github.com/astral-sh/ruff). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.

`uv format` is just a front-end for `ruff format`. It isn't introducing a new formatter to the ecosystem or anything like that.

Yeah, you can definitely use `uvx ruff` (an alias for `uv tool run ruff`) to invoke Ruff. That's what I've done in my own projects historically.

The goal here is to see if users like a more streamlined experience with an opinionated default, like you have in Rust or Go: install uv, use `uv init` to create a project, use `uv run` to run your code, `uv format` to format it, etc. Maybe they won't like it! TBD.

(Ruff is installed when you invoke `uv format`, rather than bundled with the uv binary, so if you never use `uv format`, there aren't any material downsides to the experiment.)

It's a separate binary -- we install Ruff if you invoke `uv format`. So if you don't invoke `uv format`, there's no impact on the binary size, etc.

Good questions. I don't think we'd ever deprecate Ruff because `uv format` exists, and adding `uv format` won't have any impact on Ruff's release cycles or development. The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

A lot of users just want a simpler experience. They want to install uv, run `uv run` to run their project, `uv format` to format it, etc. The idea here is to experiment with providing that functionality and see if folks find it useful. Maybe they won't want it! It's experimental :)

To clarify, `ruff` and `uv` aren't being merged. They remain separate tools. This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.

The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx?

We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to automatically install a version of PyTorch based on your machine's GPU from the PyTorch index.

pyx takes that idea and pushes it further. Instead of "just" supporting PyTorch, the registry has a curated index for each supported hardware accelerator, and we populate that index with pre-built artifacts across a wide range of packages, versions, Python versions, PyTorch versions, etc., all with consistent and coherent metadata.

So there are two parts to it: (1) when you point to pyx, it becomes much easier to get the right, pre-built, mutually compatible versions of these things (and faster to install them); and (2) the uv client can point you to the "right" pyx index automatically (that part works regardless of whether you're using pyx, it's just more limited).

> Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and then provide that registry as an entrypoint for my customers?

We don't support this yet but it's come up a few times with users. If you're interested in it concretely feel free to email me (charlie@).

uv works just as well with whatever Python you want to bring -- you're not required to use the Pythons that uv is capable of installing on your machine.

The piece of this apology that I have trouble understanding is this:

> We thought the license in the root repo wasn’t that important, so we just generated one that we thought was open.

The root repo already had an Apache license in it. If you thought it wasn't important, why replace it in the first place?

We didn't support those workflows until today. If you'd prefer a true diff:

uv adds support for projects, cross-platform lockfiles, scripts, and Python installs

Thanks dang, I appreciate it. I'd suggest something like:

uv: A unified alternative to Poetry, pipx, pyenv, and more

I wrote about it a bit here: https://github.com/astral-sh/rye/discussions/1342

Was this section removed? I'm not seeing it in the linked post.

Yeah, that's definitely within scope for what we're trying to build, and we've been hard at work on extending uv to support those workflows (platform-agnostic resolution, lockfiles, etc.). Honestly, a lot of it is already implemented, but not yet stabilized or announced. Coming soon.

(Thank you for this, it was really inspiring for me to read.)

Yeah that's right -- we make the assumption that all distributions for a given package will yield the same dependencies, similar to Poetry, PDM, and other tools. This is not strictly required by the standards, but it's very rare for it to be violated.

A lot of our core packaging development is now happening in uv [1]. Rye uses uv under the hood, so as we improve uv, Rye gets better too.

E.g., we recently added support for "universal" resolution in uv, so you can generate a locked requirements.txt file with a single resolution that works on all platforms and operating systems (as opposed to _just_ the system you're running on). And Rye supports it too in the latest release.

[1] https://github.com/astral-sh/uv

---

I work on Rye and uv, if you have any questions :)

This is a very nice article, thank you for the kind words.

This project is specifically about publishing test cases for package managers -- it's not a package manager or a registry itself. We use it in uv [1] to test that our resolver is spec compliant. pip also explored using it for the same reason.

[1] https://github.com/astral-sh/uv

[2] https://github.com/pypa/pip/pull/12580

Happy to report that this definitely isn't a paid ad. The Home Assistant team did this on their own. I helped out by building uv for some of the architectures they needed: https://github.com/astral-sh/uv/pull/2417

Thank you so much.