Conda manages binaries and their native dependencies together, including shared libraries[0]. This offers significant advantages over uv and pip when distributing packages with C extensions, such as dependency resolution that accounts for shared library requirements, and better package isolation.
The PyPI ecosystem can not, for the foreseeable future, replicate the scope of the conda ecosystem. From microarch builds to library deduplication, conda is a more general purpose solution. That doesn't mean that one "wins out" (and, for reference I predominantly use Python's PyPI), but they're not the same tools.
Does PDM manage C/Fortran library dependencies? IIRC conda was the only solution for managing both native and python dependencies but I haven't really looked elsewhere.
With wheels and the manylinux specifications there's less of a usecase for that, but still could be useful
The conda ecosystem was a early adopter of standardized binary packages.
Now it's mostly behind us, but there used to be a time where pypi didn't have wheels (a 2012 thing), or manylinux wheels (a 2016 thing) for most libraries. pip install was a world of pain if you didn't have the "correct source packages" in your system.
And now several of those projects built back then, they're no longer projects but deployed systems, might as well stick to what is working.
I agree, and yet here we are. If it wasn't built with automake I would even consider getting wheels built on the projects behalf, but I can't make heads or tails of M4.
EDIT: But let's not pretend getting cibuildwheel going for every supported variant of PythonMajVer/OS/(32/64) bit is an easy lift for small open source projects. Conda is still more ergonomic than this, although it's slowly dying because big projects have the manpower to stand up and maintain the CI pipeline for PyPI, so Conda is less and less necessary.
there was still yet a time when "open source maintainer has to build binaries for x86, ARM, OSX, Windows in order to not get complaints but owns no windows licenses, ARM machines, OSX servers", and github now gives you all of that for free / automatic / declaratively with actions + cibuildwheel. so the value add from "conda" is way down from where it started.
“Pixi instead of uv” would be a more fair comparison, as Pixi is a more modern tool which still uses the conda package format and ecosystem, much like uv is a modernised pip which still uses the PyPI package format.
One thing an conda package can do which an PyPI package cannot is have binary dependencies: a conda package is linked upon installation, and packages can declare dependencies on shared libraries. As common example is numeric libraries depending on a BLAS implementation: in a conda/pixi environment you will get exactly one BLAS shared library linked into your process, used by numpy, scipy, optimisers, etc. For some foundational libraries like BLAS which have multiple implementations, the user even has the power to consistently switch the implementation within the environment, eg from OpenBLAS to Intel’s MKL.
The PyPI package format does not allow binary dependencies: wheels must be self-contained when it comes to binary code (not when it comes to Python code - which hopefully makes it clear that something here is inconsistent). Take any numerical python environment and enumerate the copies of BLAS you have, it is probably 3-5. All running their own threadpools.
Another very simple example is with inbuilt modules depending on native code, like the sqlite3 module. In a conda/pixi installation you are guaranteed that the python binary links against the same sqlite3 code as the command-line sqlite3 cli tool in the same environment. Stuff like this removes many cross-language or cross-tool hassles.
I prefer uv or poetry if I’m doing anything simple or pure python (or perhaps with a small binary dependency like an event loop). But pixi is the way to go for large environments with lots of extra tools and numerical libraries.
I use it because I do not need to create packages, and I often do a lot of interactive coding within a conda environment, not just running full Python scripts. At any given time I have a primary conda env I'm using with my set of daily use packages, eventually creating a new one for testing when there are major version upgrades to Python or a package I use frequently.
When I read the uv docs and see other people's examples, I have a hard time understanding how it works for my workflow. It seems I could continue using conda for environment management and only use uv for package installation and it would be much faster, but that also feels a little shaky and potential for error combining the two tools, and since mamba became the default solver conda is pretty fast, even when building a new env from scratch.
It feels like conda and it's ability to have multiple Python versions, with env management built in, gives me more than uv, just without the package installation speed. But I am certainly open to someone explaining uv to me in a way to disprove that
These days I see Conda (and micromamba) used as a reliable cross-platform winget/apt/yum/brew. For example, to install GDAL.
uv replaces pip, conda and pip have been complementary for a long time. But I would be surprised if uv does not take on conda at some point, e.g. with a micromamba subcommand.
[0]: https://docs.conda.io/projects/conda-build/en/latest/resourc...