Uv - another Rust tool written to replace Pip

[charliermarsh (Charlie Marsh)]

@pradyunsg

• How useful the standards were in building something that would transparently interoperate with existing tooling (AFAICT, that’s what it’s doing!)? Did you need to rely on looking at the existing Python implementations for various cases (since you have reimplemented lots of stuff in Rust)?

Extremely useful. Like, everything here was extremely useful and referenced heavily. Same with PEP 503, PEP 691, and others. Speaking personally, a few things that come to mind with respect to challenges:

• In implementing our PEP 517 front-end, I did have to refer back to pip and build’s source a lot to understand how those tools handle various edge cases (e.g., pyproject.toml is present but has no build-system; build-system is present but has no build-backend). We basically discovered limitations through testing and then referred back to pip and build to understand how they overcome them.

• There was a lot of “What does pip do?” for requirements.txt, but my understanding is that requirements.txt is more-or-less pip-specific and not intended to be covered by a spec per-se. (I’m aware of the pip documentation on it, perhaps there’s more elsewhere.) For example, we had some bugs around resolving relative paths for -e vs. -r. And I didn’t realize that it supported remote URLs for requirements and constraint files. (I’ve somehow never used that feature in my entire career!)

• There was more “What does pip do?” when investigating obscure behaviors, e.g., a --constraint file that itself includes a nested -r or -c file.

The other, related topic that comes to mind for me here is testing. This isn’t really a “standards” thing, but we did put a lot of effort into building infrastructure to test out specific, obscure scenarios, both for testing correctness and error messages. This is available as packse, which was inspired by pip-resolver-benchmarks. So, testing standards compliance was and still is hard.

The other testing-related problem that we’ve run into is that it’s hard to test against a wide range of custom indexes (e.g., Artifactory, Azure, AWS, etc.), so we unknowingly released with lack of support for some of those given odd behaviors they exhibit, but mostly around credentials and such. This isn’t really about the packaging standards as much as a challenge in practice with building a packaging tool: it’s just hard to test against a wide range of indexes without standing up a bunch of indexes yourself.