Shameless copy from #26245. Thanks @jluttine !
cc @layus

To do:

• rename to miniconda?
• miniconda3 (3.6) and miniconda (2.7). Perhaps also anaconda?
• darwin, though out of scope for this PR
• fix meta
• some option to specify packages and/or env variables. We could make it easier overridable.

Works for me :-).

Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

I'm not sure what exactly is meant by the suggestion "rename to miniconda" so I thought I'd give my comment: It's possible to add different installers for Miniconda vs Anaconda and Python 2 vs 3. So one could replace conda-install with four different installers miniconda-install, miniconda3-install, anaconda-install and anaconda3-install if wanted. The current conda-install is Python 3 miniconda installer. But in other places I would keep the term conda instead of renaming to miniconda because Miniconda is just a minimal installer for Conda and its dependencies. That is, I would keep the default path ~/.conda, the command load-conda-shell and the package name conda as such.

@layus

Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

Maybe we can just passthru the current environment somehow? I suppose this issue didn't exist when using nix-shell.

@jluttine what I mean is to indeed add all installers. However, there would be a separate derivation for each and so we keep the name conda-install for each of them.

That is, I would keep the default path ~/.conda, the command load-conda-shell and the package name conda as such.

Definitely

@FRidh I'm not too familiar with the "derivation" term. So how would the users use the different installers?

Something like this:

nix-env -iA miniconda3
load-conda-shell
conda-install

or

nix-env -iA conda
load-miniconda3-shell
conda-install

or

nix-env -iA conda
load-conda-shell
miniconda3-install

or something else? I mean, at what point and how users choose the installer?

@jluttine

nix-env -iA conda.miniconda3
load-conda-shell
conda-install

Ok. Indeed, adding all installers inside the same conda shell derivation would cause downloading all the installers to nix store even if only one of them is used inside the conda shell. However, this could be avoided if instead of downloading the miniconda/anaconda installers to store, we would just add simple scripts (e.g., miniconda3-install) which fetch the correct installer from the Continuum repo only when called.

So, for instance, miniconda3-install would look something like:

wget https://repo.continuum.io/miniconda/Miniconda3-${version}-Linux-x86_64.sh -O /tmp/miniconda.sh
chmod +x /tmp/miniconda.sh
bash /tmp/miniconda.sh -b -p ${installationPath}

And similarly for miniconda-install, anaconda-install and anaconda3-install. Then we could have all the installers inside one derivation conda and the user can use whichever (s)he prefers without the overhead of having multiple big Anaconda installers in nix store. But is this approach bad in some other way?

EDIT: sha256 hash checking could be added after wget.

@layus

Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

Maybe we can just passthru the current environment somehow? I suppose this issue didn't exist when using nix-shell.

Well, I have no idea, I didn't use nix-shell. But it's not really important for the release.

Is there any hope of getting this merged any time soon?

Hello,
Is there anything happening here?

Closing in favor of #34872.