I would love to see people try it out or integrate it into their projects. We are going to work on integrating rip into pixi very soon and hopefully have something to show at the end of November. Until then you can try rip standalone with cargo run -- flask (or any other package). Another big topic that we will have to work on for real-world scenarios is sdist support …
@bernatgaborrip totally supports custom pypi indexes (we tested with the pytorch one). And also does not require any conda package at all It looks at whatever python it finds on your $PATH and uses that to populate the environment markers.
This is very cool and seems relevant to some recent packaging discussions [1].
It’s cool that the solver works with both indexes. I’m curious, do you think there’s a way to cross the conda-forge / PyPI boundary while resolving? I’ve been thinking about this lately and it seems doable but there are some potential pitfalls. One obvious one is that the package names aren’t exactly 1-to-1, but I don’t know how often.
I’m thinking of the scenario where I want to install A from PyPI and it requires B which is on both PyPI and conda-forge. conda install A doesn’t work because A isn’t there. pip install A will install B from PyPI (let’s assume I don’t want to do that for some reason).
Right now the solution is conda install B; pip install A but it’d be great if a tool could figure that out on its own. There are a lot of recipes on conda-forge that could be removed[2] if conda knew to install from PyPI when needed.
❯ cargo install rip
Updating crates.io index
Downloaded rip v0.0.1
Downloaded 1 crate (295 B) in 2.34s
error: there is nothing to install in `rip v0.0.1`, because it has no binaries
`cargo install` is only for installing programs, and can't be used with libraries.
To use a library crate, add it as a dependency to a Cargo project with `cargo add`.
Or is there no frontend just yet? I seen no sdist support for now, is that correct? I tried using through pixi, but that does build on conda, based on outputs. (In a parallel world I’d like to replace pip with rip, not sure if that’s on the roadmap).
The problem is that – to build a conda-forge package – even one with binary extension, you might need some lower-level noarch package. So even at package-build time the resolver might have to pull some packages from PyPI and not conda-forge. Not sure if we want to do that given the pretty different operating model of PyPI vs conda-forge, but let’s see how these things evolve
@bernatgabor
I think the rip crate on crates.io is something else, indeed! For the moment you need to pull the repository, and then run cargo run. E.g.:
git clone https://github.com/prefix-dev/rip
cd rip
cargo run --release -- flask
I think there is currently no way of specifying the path to the python executable, but the rip binary will look into your PATH variable and find the first one available.
From Rust, it would be very easy for you to give a concrete path to a Python executable (instead of searching on PATH).
I do think this would require a CFEP or something similar to define how it should work, but I think it’d be a major improvement to the ecosystem if it’s possible.
It looks at whatever 
not having to clone and copy things around. Then you can also use 
because, well on any reasonable sized project there will be some dependencies that don’t have wheels.