rip is the PyPI plumbing underneath pixi, not a package manager

A library, not a package manager

rip is described as a library that allows the resolving and installing of Python packages from PyPI into a virtual environment, from Rust. The framing matters, because the documentation spends a sentence ruling out the most common misunderstanding. The library is not a package manager itself but provides the low-level plumbing to be used in one, and it should be fast and easy to use in the same way the authors describe their Conda-side project, rattler. The reference implementation to look at is pixi, the package manager the same organisation builds on top of this kind of machinery, and the work itself is credited as based on the quite excellent work of posy, with the authors credited where possible. So the intended audience is narrow and clear: people writing a Python packaging tool in Rust who do not want to reimplement dependency resolution, metadata fetching and wheel installation. If you are looking for something to install packages with today, pixi is the product and rip is the engine under it.

Resolution is delegated to the Resolvo SAT solver

The dependency resolution is not written from scratch. rip integrates the stand-alone packaging SAT solver Resolvo, and the mechanism is incremental: the solver adds packaging metadata during the resolution of the SAT problem, so metadata is fed in as the solve proceeds rather than being collected up front. That matters for a PyPI resolver, where the dependency graph is discovered while it is being solved. The feature is gated behind a Cargo feature flag named `resolvo`, so the solver path can be turned on or off at build time. The output of this stage is a resolved set of packages, which the next stage installs. For a team writing a tool on top of rip, the separation is the useful part: resolution, downloading and installation are distinct concerns, and the SAT solving step is replaceable without rewriting the rest.

Metadata is fetched asynchronously and cached hard

The feature list names async downloading and aggressive caching of PyPI metadata, and the description of the test run spells out what that means in practice. Everything is cached locally so the PyPI metadata can be reused, which is what makes repeated resolutions fast and what keeps a tool from hammering the index on every invocation. The feature list also includes the caching of locally built wheels, which is a separate cache from the metadata one and matters for anyone who builds a package from a source distribution and then installs it again. The listed feature set is short and explicit: async metadata download with caching, resolution with Resolvo, installation of wheel files, support for sdist files, and caching of locally built wheels. The documentation is also candid that more intricacies of the PyPI ecosystem need to be implemented, and points at the project's issue tracker for the detail, which is a reasonable way for a library at this stage to publish its gaps.

Source distributions only work if they follow PEP 517 and PEP 518

Support for sdist files is listed as a feature, and the parenthesis carries the condition that matters: they must currently adhere to the PEP 517 and PEP 518 standards. That is the standard path for building a package, so in practice the requirement is that the build backend is declared and the build requirements are spelled out rather than assumed. The installation support itself is described as very simple, and the documentation is careful about its scope, saying it should be used for testing purposes exclusively. The example creates a virtual environment and installs a package into it, after which you start the interpreter from that environment and import the package to confirm it resolves. The acknowledged gap is worth stating plainly: there is no detection of existing packages in the virtual environment yet, although the documentation notes this should be relatively straightforward to add. For a tool that recreates environments often that is a small gap, and for a tool that must respect a pre-existing environment it is a real one.

A workspace of crates, built with a pinned toolchain

The repository is a Cargo workspace rather than a single crate. The manifest sets the workspace members to `crates/*` and the resolver to version 2, and the shared package metadata gives the workspace version as 0.10.0 with the edition set to 2024 and a minimum supported Rust version of 1.90. The licence is BSD-3-Clause, which is permissive and lets a commercial product embed the library without the copyleft obligations that would come with a different choice, though it is not a legal opinion on your particular use. The release metadata allows branches of `main` only, consolidates commits and uses an empty tag prefix, so the tags look like plain version numbers rather than prefixed ones. Alongside the crates there is a `pixi.toml` and `pixi.lock`, which is the same tool the organisation's own package manager uses, plus `end_to_end_tests/`, a `test-data/` directory, a `rust-toolchain` file, a `.pre-commit-config.yaml` and a `cliff.toml` for changelog generation, and a `CHANGELOG.md`.

No releases, and a last push in August 2026

The maintenance picture is modest. The repository has no GitHub releases, so the version in the manifest, currently 0.10.0, is the version you would depend on, and the changelog in the repository is the record of what changed. The last push to the repository was on 2026-08-05, and the repository is not archived. The homepage for the organisation is prefix.dev, and the documentation for this project is published separately, with the main branch docs linked from the README badge. Two things are worth separating in an evaluation. The first is that a library without tagged releases is awkward to depend on, because there is no published artefact to point at, and the version has to be tracked in the manifest or the changelog. The second is that this project sits next to pixi in the same organisation, and pixi is where the incomplete pip-like binary described in the documentation is used for testing installs. A team building a tool on rip would be taking on the parts that the documentation explicitly calls very incomplete.

Editorial conclusion

Rust developers building a Python packaging tool, a language server for Python environments or anything else that needs to resolve and install from PyPI will find rip the right layer to build on, since it handles the resolver, the metadata cache and the wheel install path and leaves the user interface to you. It is the wrong choice if you want a command line package manager, because the documentation says outright that it is not one, and the wrong choice for a production install path while venv detection is missing. Before adopting it, read the feature list against your needs, check that the `resolvo` feature flag covers your resolution cases, and test the sdists path with your own packages, since those must currently adhere to the PEP 517 and PEP 518 standards.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. prefix-dev/rip on GitHub
4. Project website
5. README