What about pixi and rip?

[olivier-lacroix]

Hello there,

I have been looking forward to improved package management for python, and am excited by the uv announcement. I have also been following with interest the developments made by the prefix team in pixi and rip.

Benchmarking uv with rip seems to show, anecdotally, that rip is as fast or faster than uv (I may be doing this completely wrong though):

❯ hyperfine --warmup 3 'cargo r install dagster /tmp/ripenv' 'source /tmp/uvenv/bin/activate;uv pip install --reinstall dagster --no-cache'
Benchmark 1: cargo r install dagster /tmp/ripenv
  Time (mean ± σ):      6.959 s ±  0.236 s    [User: 9.346 s, System: 0.370 s]
  Range (min … max):    6.643 s …  7.335 s    10 runs

Benchmark 2: source /tmp/uvenv/bin/activate;uv pip install --reinstall dagster --no-cache
  Time (mean ± σ):      7.829 s ±  0.819 s    [User: 0.808 s, System: 1.080 s]
  Range (min … max):    6.183 s …  8.809 s    10 runs

Summary
  cargo r install dagster /tmp/ripenv ran
    1.13 ± 0.12 times faster than source /tmp/uvenv/bin/activate;uv pip install --reinstall dagster --no-cache

Pixi and uv seem to have very similar goals (albeit pixi ambitions to cater to other languages than python).

I am wondering about the opportunities to share, at least, (some) underlying libraries to achieve these goals faster.

[zanieb]

Hi!

We've talked to each other before and there's definitely more that we can do together, but it's worth pointing out that there has already been collaboration — it's just not obvious.

For example, they are using a couple foundational crates that @konstin published e.g.

• pep440_rs
• pep508_rs

And we are using an HTTP crate from them:

• async_http_range_reader

Additionally, all of our test scenarios have also been open source at packse long before we announced uv — they recently made use of a couple of these in their test suite. I'd love to see these test cases adopted across the Python packaging ecosystem, e.g. they would be useful to ensure behavior confirms in pip, poetry, etc.

One barrier to collaboration is that they use a different resolver than us; they wrote resolvo but we are using PubGrub. These solvers have some fundamental differences, and during our design phase we decided to commit to PubGrub instead of a libsolv-style solver. However, we're working closely with the pubgrub-rs maintainers who have also expressed interest in working with their team:

• Cooperation with PubGrub-rs. prefix-dev/resolvo#2
• Improve error messages prefix-dev/resolvo#9 (comment)

And work on pubgrub-rs has far reaching implications for resolvers across language ecosystems, e.g. the authors would love to see it used in Cargo some day:

• resolver error messages as good as PubGrub rust-lang/cargo#5284

We have more crates in uv that we can publish for shared-use once we stabilize them, but everything is permissively licensed and open source.

We're excited to have everything public now — it's going to make collaboration a lot easier.

Regarding benchmarks, it's tough to create a robust benchmark. If you're interested in exploring it, I'd recommend adding rip support to our bench script.

[charliermarsh]

Thanks, I appreciate this! Agree with everything @zanieb wrote above. We've chatted with various folks on the Prefix team at different points in time, and my feeling is that we just have different goals and focus areas (though with some overlap of course). But at the very least, there will still be opportunities for us to collaborate on some of the underlying libraries (like those mentioned above).

On the benchmarks... Benchmarking is tricky. We put a lot of time into the benchmark script in the repo. As a heads up, the command above seems to be comparing rip with caching against uv without caching. (rip has a persistent cache, but doesn't currently expose command-line flags to modify it, based on my read.) I think it's also using a debug build for rip but a release build for uv. The details are hard to get right 😂

I'm happy to produce some rigorous benchmarks if folks are interested -- we could probably add rip to our benchmark script. I just re-ran the command you used above, comparing release builds and clearing the cache between invocations:

❯ hyperfine --prepare "./target/release/uv venv" "./target/release/uv pip install -r requirements.in -n" --prepare "rm -rf ~/Library/Caches/rattler/pypi/ .venv" "../rip/target/release/rip install dagster .venv" --warmup 10 --runs 20
Benchmark 1: ./target/release/uv pip install -r requirements.in -n
  Time (mean ± σ):      1.267 s ±  0.129 s    [User: 0.419 s, System: 0.807 s]
  Range (min … max):    1.070 s …  1.573 s    20 runs

Benchmark 2: ../rip/target/release/rip install dagster .venv
  Time (mean ± σ):      3.379 s ±  0.244 s    [User: 0.851 s, System: 1.003 s]
  Range (min … max):    2.987 s …  3.927 s    20 runs

Summary
  './target/release/uv pip install -r requirements.in -n' ran
    2.67 ± 0.33 times faster than '../rip/target/release/rip install dagster .venv'

So that shows something like a > 2.5x speed-up with uv, but it'll vary across platform, machine, etc. (I took the median of three runs).

[olivier-lacroix]

Thanks @charliermarsh and @zanieb !

Started to add pixi in the bench script in #1581

[wolfv]

Hey 👋

Indeed, the differences are nicely pointed out by Charlie and Zanie and we're just as happy to collaborate on some of the underlying issues.

I also did some benchmarking and indeed uv is a little faster, for the following reasons:

• rip rigorously checks SHA256 hashes of the RECORD files inside packages, and uv seems to skip that. pip also skips that (which is why some Python packages actually ship with broken hashes)
• rip's cache is currently storing wheels as zip files while uv stores the extracted files. This is something we need to change in rip, but shouldn't be particularly hard (we pay the cost of re-extracting the packages each install time). We also already do that for conda packages.
• We check if new packages are on PyPI everytime instead of adhering to the 10 minutes Max-Age. This is behavior that we adopted from pip – we'll make this configurable in rip.

And lastly rip and uv share some performance problems, e.g. urllib botocore is pretty tough to resolve.

Anyways, as Charlie and Zanie mentioned we do share a bunch of underlying crates and hopefully we can share more going forward :)

[notatallshaw]

On the topic of resolver benchmarks, can I suggest that people take a look at the approach pip-resolver-benchmarks takes.

My understanding is the library is experimental right now, but being able to collect full real world scenarios at a point in time and elliminate network variability (without just relying on cache) are both very helpful.

[zanieb]

Thanks for the reference! That project inspired our packaging scenarios — we're very interested in being able to use those benchmark scenarios as inputs.

And thanks for chiming in Wolf!

Here are some issues regarding the behaviors mentioned:

• Support hash checking against RECORD #888
• Override max-age response header to 0 #505

[tekumara]

we decided to commit to PubGrub instead of a libsolv-style solver

just a question to satisfy my own intellectual curiosity around resolvers, what made you settle on PubGrub over libsolv or alternatives?

[JelleZijlstra]

just a question to satisfy my own intellectual curiosity around resolvers, what made you settle on PubGrub over libsolv or alternatives?

FYI Charlie talks about that here:

https://discuss.python.org/t/uv-another-rust-tool-written-to-replace-pip/46039/56

[ruben-arts]

Following up on @wolfv's response,

We've decided to integrate uv into pixi to avoid double work and to be able to contribute to the same code base. This allows us to refocus on conda specific work. Killing rip as of immediately, but taking what we've learned and hopefully being able to support uv with it.

[zanieb]

Thanks for the update! I'm going to close this as I think all the major questions here have been answered.