zanie

> FYI: The extraction of files is largely python code that doesn't release the GIL. (cf. the zipfile class from the python interpreter has large layers of abstraction with a massive overhead in python code).

TIL. I ran some benchmarks and confirmed this is the case for many small files as you'd see in wheels — the GIL is released in a meaningful way for larger files though. Thanks!

> This might not give the same result for uv though.

Yeah, I built a prototype and ran some benchmarks. It makes a big difference if the entire wheel is empty files but for any real world examples it's within noise of the baseline.

I'm a bit confused. pdm hit 1.0 in 2021, 3 years before uv was released.

If you want to open an issue with verbose logs (`-vv`) I'd be happy to look into it. You can set `UV_LOG_CONTEXT=1` to emit timing information.

If you're running Python scripts, I'd recommend using `uv lock --script <path>` to generate a lockfile — we don't do that by default for scripts yet but that will avoid unexpected upgrades.

(I work on uv)

We want to support that workflow / experience but we want to design it differently because there are a lot of nuances to pip's interface and the pip maintainers have encouraged us to rethink it.

It's also non-trivial to implement because of how our cache design differs from pip's.

Yes! It's in progress — it's already there, just hidden as we iterate on it.

(but as a note, the initial `uv lock` will already attempt to choose the highest possible versions and `uv lock --upgrade` will do so again, requests for `uv upgrade` are generally centered around changing the constraints in the `pyproject.toml`)

It makes `uv run <project-name>` work by default, I expect most projects to need an entry point.

So far the maintenance burden has been quite bearable and extending pip provides us with an opportunity to explore and encourage improvements upstream which are still beneficial to a lot of people.

I hadn't considered that, it's an interesting idea. We generally hold a very high bar for nagging users or gating behaviors. It's possible we'll reach a point someday where this is appropriate! I think you're right that we need to teach people better workflows, but that's happening organically as use of the tool grows and people's first exposure to a Python project is `uv init` and `uv add` rather than `pip`.

Unfortunately dynamic metadata is not efficient for package resolution, so we don't want to encourage it. Instead, we want to design a better workflow for using source control for versioning, but haven't had the time to do so.

Pixi is very focused on the Conda ecosystem and implements a sort of bridge across the Conda and PyPI ecosystems. I am very interested in solving the problems that motivated creation of the Conda ecosystem, but I want to do so by driving forward the PyPI ecosystem so those use-cases can be addressed in _many_ tools instead of just one. This is the main reason you don't see us pursuing Conda package support in uv directly (in the style of Pixi).

There have been several threads about us collaborating or converging, but there are no concrete plans to do so at this time. We share some Rust crates, e.g., Pixi uses our internals to solve the PyPI-side of their dependencies, and we occasionally fix or change things for each other.