Add Pixi as an installation option?

[denkiwakame]

Would it be possible to consider adding Pixi as an installation option (primarily as a modern alternative to conda written in Rust) in the installation guide? https://github.com/facebookresearch/faiss/blob/main/INSTALL.md

Pixi is a Rust-based, modern re-implementation of the conda package manager, offering ~10× faster performance and built-in lockfile support, with a strong focus on reproducibility in scientific environments. https://prefix.dev/blog/pixi_a_fast_conda_alternative

A minimal example for faiss installation would be:

pixi init -c pytorch -c nvidia -c conda-forge
pixi add faiss-cpu=1.13.1   # blazing fast 🚀 (0.47s)

pixi init -c pytorch -c nvidia -c conda-forge
pixi add faiss-gpu=1.13.1   # blazing fast 🚀 (0.63s)

Pixi is increasingly adopted across the scientific Python + non-Python (C++,BLAS, etc.) ecosystem. For example:

• SciPy now lists uv and pixi as standard installation options: https://scipy.org/install/
  • also actively replacing CI env management with pixi CI: use pixi to manage environments scipy/scipy#21489
• PyMC recommends pixi for environment management: https://www.pymc.io/blog/getting_started_with_pymc.html#q-what-about-uv-for-installation
• Meta Momentum also provides pixi-based installation instructions: https://github.com/facebookresearch/momentum
• pyslam also: https://github.com/luigifreda/pyslam

Additional context:

• We have been using Pixi in research projects involving faiss for nearly a year, including GPU/CUDA versions and cuVS, and everything has worked smoothly.
  Examples: https://github.com/denkiwakame/pixi-faiss-examples
• Recently, some users have expressed serious concerns about licensing issues, and this has sometimes led to a kind of cancel-culture sentiment not only toward Anaconda Inc., but unfortunately toward the broader conda ecosystem including conda-forge, which is fully open and community-driven. uv pip install support #4510
• These discussions often reflect a broader trend:
  many users still develop misconceptions around “conda” vs “defaults” vs "conda-forge" vs “Anaconda Inc.” which sometimes leads to unnecessary confusion or negativity.
  • As a result, discussions can sometimes drift away from what really matters for the research community, reproducibility, and toward debates about modern package managers.
• Pixi avoids defaults entirely and aligns cleanly with the conda-forge ecosystem. (it also privides a modern, fast workflow) https://prefix.dev/blog/towards_a_vendor_lock_in_free_conda_experience
• Although I regularly use both uv and pixi, Pixi is by far the most reliable option when dealing with non-Python dependencies (make, cmake, clang, swig, boost, OpenMP, BLAS, CUDA, ...) and when strict reproducibility is required. (we can lock everything).

If there is any openness to this idea, I would be more than happy to contribute a draft PR.
Thank you again for your continued work on faiss.

[mnorris11]

The package manager is still Conda, so I am unsure if it solves the concerns of the users from the other thread. It may be a question for the users in the other thread. We already avoid defaults in Faiss.

We are not necessarily opposed to using pixi, other Meta OSS projects use it too, but we would need to know if it's worth the effort.

As maintainers, our goal is to make Faiss

• Easy to use for everyone
• Reasonable to maintain

Conda has struck a balance so far because we can pin the dependencies for non Python packages.

For non-conda land, understanding the model and what we will support for non-Python dependencies is likely the biggest part of the work required for supporting a Pypi package manager like pip / uv.

[denkiwakame]

@mnorris11 Thank you for your comment & consideration,

The package manager is still Conda, so I am unsure if it solves the concerns of the users from the other thread.

While pixi is in principle conda package mangaer, the key difference is that it does not rely on user-side configuration. Conda/miniconda enables the defaults channel by default, and avoiding it requires explicit user action (e.g. editing .condarc), which many users never take; tools like pixi remove this pitfall unless users intentionally opt into it ¹.

It may be a question for the users in the other thread.

yes, slightly off-topic, IMHO it’s a bit unfortunate that the entire conda ecosystem is sometimes dismissed based on impressions from the “vanilla conda” era and its proprietary channel, even though modern tools like pixi address many of those pain points ²³.

if it's worth the effort.

Adding pixi just as an installation option (e.g. pixi add faiss) would require no changes to existing conda packages.
It provides a fast and simple way for both pip and conda users to try faiss ⁴.

Using pixi for source builds is a separate question, but in practice it tends to be much easier and significantly faster (5–10x) than vanilla conda (it also saves CI costs), while also enabling fully reproducible build environments via lockfiles ³.

Conda has struck a balance so far because we can pin the dependencies for non Python packages.

I completely agree with this point.

On the PyPI side, making native dependencies work reliably requires substantial hidden effort ⁵⁶⁷, and fully reproducible source builds often end up relying on Docker images, which is not always ideal for researchers.

If ideas like introducing pixi help more users use faiss comfortably, I’d be very happy to contribute in any way I can.

Footnotes

1. pixi's default channel is conda-forge https://github.com/scipy/scipy/issues/21489#issuecomment-3296279440 ↩

2. https://pixi.sh/latest/#what-is-the-difference-with-pixi ↩

3. https://proceedings.scipy.org/articles/nwuf8465 ↩ ↩²

4. Pixi also supports pypi package managements with uv backend https://prefix.dev/blog/uv_in_pixi ↩

5. https://pypackaging-native.github.io/key-issues/native-dependencies/blas_openmp/ ↩

6. https://pypackaging-native.github.io/key-issues/simd_support/ ↩

7. https://pypackaging-native.github.io/key-issues/gpus/ ↩

[mdouze]

See also https://github.com/facebookresearch/faiss/wiki/Installing-Faiss#why-dont-you-support-installing-via-xxx-

[denkiwakame]

I fully agree with what is written in this wiki.
The concerns around CI support, controlled environments, and maintenance cost all make sense.

my understanding is that pixi primarily reuses existing conda(-forge) binaries and should not introduce additional compatibility issues for Faiss itself.

If there are specific concerns or failure modes you anticipate with pixi, I would be interested to learn more.