pixi VS rip

re: C/C++ development: anybody using conda/pixi for dependency management? Here's an example of compiling a C++ SDL program using pixi and the SDL dependency from conda-forge [1].

Seems viable as a replacement for things like vckpg [2] which only builds from source.

I'm still researching this but it seems like rattler [3] is the tool to use to build/publish packages. The supported repos are: prefix.dev's own hosting, anaconda.org, artifactory or a self-hosted server.

--

1: https://github.com/prefix-dev/pixi/blob/main/examples/cpp-sd...

2: https://github.com/microsoft/vcpkg

3: https://prefix-dev.github.io/rattler-build/latest/authentica...

I recently started using https://github.com/prefix-dev/pixi for Python projects. I really love it so far, but this tool looks a bit more mature, which makes sense considering pixi is relatively new.

Have you tried https://pixi.sh/ ? It brings Cargo/NPM/Poetry like commands and lock files to the Conda ecosystem, and now can manage and lock PyPI dependencies alongside by using uv under the hood.

I haven't been using anything CUDA, but the scientific geospatial stack is often a similar mess to install, and it's been handling it really well.

Isn't this basically what pixi wants to be? Wouldn't it be better to work together?

https://github.com/prefix-dev/pixi/

There are a couple of promising tools written in Rust looking to replace Pip for most users.

Rip (https://github.com/prefix-dev/rip/issues) which is more of a library for other rust tools to be on top of like Pixi (which is looking to replace both Pip and Conda).

And now uv, which seems to be looking to replace Pip, Pip-Tools, and eventually Poetry and PDM.

A lot of the explosion in tools in the Python world is coming from the desire for better workflows. But it has been enabled by the fact that build configuration and calling has been standardized and tool makers are able to follow standards instead of reverse engineering easy install or setup tools.

I know a lot of people are put off by there being so many tools, but I think in a few years the dust will settle and there will emerge a best practice work flow that most users can follow.

As a primarily Python developer and someone who occasionally contributes to Pip to solve complex dependency resolution issues it does make me wonder if I should hang my hat on that and learn enough rust to contribute to one of these projects eventually.