Hacker News new | ask | show | jobs
by matrss 319 days ago
Anaconda != the conda ecosystem != Python

Everyone who is comparing Anaconda and conda to Astral and uv is missing that the conda ecosystem is language-agnostic while uv is python specific. uv won't help you install gfortran, for example. It is not a replacement, unless you only do python (and use at most common non-python libraries that are available on PyPI).

On the other hand you don't have to use anything associated with Anaconda to use the conda ecosystem. Alternative package managers like mamba and pixi rely on the conda-forge channel instead. Pixi in particular (https://pixi.sh/) is sort-of the uv for the conda ecosystem workflow-wise, and works pretty well if you want that.

3 comments

I admit I'm not super well versed in what conda's main uses are. Python's whole tooling situation has felt like a nightmare & I've tried to keep far away, but I've had to face it a lot more recently because it's so prevalent for AI. Thankfully uv seems to have done a huge amount of what I need.

Still, if the concern is language-agnostic ways to use tooling, mise (nee rtx) is the 1000 pound gorilla in the room today. Incredibly fast well built Rust based tool that has really massively expanded in scope & offerings, with grace & elegance. I thought it was an asdf replacement, for installing/using toolchains, for .tool-versions files. But it's really grown to be a lot more, capable of letting you isolatedly manage tools it can install from a huge variety of backends (pip, npm, cargo, others). https://mise.jdx.dev/dev-tools/backends/

Hadn't heard about that before, looks interesting. But AFAICS mise focuses on installing tools, not actually all dependencies. It integrates with the languages dependency management tools, which doesn't help you if the language doesn't even have one or the integration wasn't written yet.

I'd rather see more adoption of guix for this purpose. It is a single package manager with a functional approach that allows for introspection of all dependencies (down to the bootstrap toolchains used to build the bootstrap toolchains that build your toolchains, which is something that AFAIK no other package manager except for nix can do), has a fairly large package repository, straightforward locking, actually tested packages, and very easy build recipes (unlike conda-forge...).

If you are in a commercial environment, I can only warn to think that using alternative conda clients will be safe. Condaforge for instance will happily download from the main channel if the recipe requires it. It's pretty hard to make sure this does not happen, best solution is to block access on a network level.
Do you have an example for a package on conda-forge that actually does this? I can only find a vague announcement from 2021 that the "defaults channel is now dropped when building conda-forge packages", as well as statements that the conda-forge repositories are considered incompatible with the defaults channel and having both enabled is an unsupported configuration. Access is blocked on the network level anyway.
That can only happen if you as a user have the 'defaults' channel still configured as available, and conda-forge considers it a user error whenever this happens (the official line is `conda-forge is incompatible with the packages provided in defaults`). Many bug reports are closed simply by telling the user to fix their channel priorities and stop mixing the two
Correct, it's a user error, but in a corporate environment, this happens. Many scientists have their own recipes and you can't catch them all.
So with a fresh installation of one of those alternative conda clients and no user intervention it won't happen, right? On top of that you can block access on the network level as well.

Sure, when your employees are outside of the corporate network they can still download stuff from the default channels, but in the end it is no different than any other license violation they could do. At least with Anaconda there is a semi-effective fix.

I use Miniforge in a commercial environment and never found a package downloading from the main channel. I'm pretty sure a recipe that does that would be blocked by conda-forge reviewers.
And how many people (count them with fingers) use Conda for anything other than Python? It’s a bloatware. People stopped using Conda because these people kept making the bloat worse.
A single one of the gfortran packages released about 20 hours ago already has 362 downloads, so I think it is safe to say that the non-python users of conda-forge are more than just a handful.

If you don't need it that's fine, no one is stopping you from using PyPI and uv instead. But for some that is not a replacement.

And yes, some things about conda(-forge) could be described as bloated. I particularly dislike the convoluted packaging process.

It is always tradeoffs and deciding based on your own use cases. E.g. if you want to distribute tested packages to users of your software then both conda-forge and PyPI are ill-suited for you. They (and most other package managers) do install-time dependency resolution, so the installation cannot be guaranteed to be tested as working at all. Some package managers do that better, so is conda-forge and PyPI obsolete now?

362 downloads over 20 hours isn't that impressive. Not saying Anaconda isn't great. Don't have much experience with it but I hope the devs get paid for all the value delivered, which I think is largem
Well, it is more than a handful, that was the only point.

You seem to be conflating Anaconda with the conda ecosystem. This package is from conda-forge, which is a community project sponsored by Anaconda but otherwise unrelated to it.

I couldn't care less for Anaconda, but with conda-forge and pixi there is a decent general purpose and language-agnostic package management tool for development purposes in the conda ecosystem.

See, why are you adding forge in there? Why do you think forge exists?
What does it change? Conda-forge users are users of the conda ecosystem. You suggested there is only a handful of those that use it not for python, I provided a counter point.

Or did I misunderstand you and what you meant with "conda" was either anaconda, or conda-the-software? But then the comment about Python doesn't make much sense.