Miniforge for Education

[Adamtaranto]

Comment:

Hi All,

I'm part of a working group with The Carpentries, a non-profit org that runs intro data science and coding workshops for researchers. Following Anaconda Inc.'s decision to start suing research orgs over use of their formerly free software, we are currently exploring alternative solutions for getting students started with Python.

Would the team here be open to adding a "miniforge for education" version in the releases that could be used as a drop in replacement for Anaconda?

Our goal is to streamline the setup process for students who may not have opened a terminal before.

Some specific features I had in mind:

• Including core sci packages in the base env (numpy, scipy, pandas)
• Including packages for editing notebooks (jupyter, ipykernel)
• Add miniforge to ~/.bash_profile by default (rather than running conda init bash in the miniforge prompt) so that conda is available in GitBash for windows users without additional steps.
• Create a PKG installer for OSX to avoid having to explain how to run a shell script during set up.

Tagging in @tobyhodges, Director of Curriculum @ The Carpentries.

[hmaarrfk]

You should be able to fork miniforge and add what you need to the bottom of:

miniforge/Miniforge3/construct.yaml

Line 55 in 168f4d5

- pip

As for why I don't think this is appropriate for conda-forge:

1. Adding to the base env is strongly discouraged since it can lead to difficulties in updating conda itself. see Preventing modification of the base environment #636
2. Jupyterlab is a heavy dependency. Not suitable for a "minimal" installer like "miniforge". VSCode is a totally separate application.
3. Add miniforge to the ~/.bash_profile is actually a nono. You would have to add it to the .bashrc and this isn't really nice to do by "default".
4. For a PKG installer. Please see the work done enable pkg installers #434 It would be great if you could work on it:
   • Fork
   • Add and improve.
   • Review
   • Repeat improve + review steps
   • we merge
   • you continue to be involved!

1-3 are hard sells for miniforge since the audiance goes beyond "first time python users". They are however 1-4 line fixes that you can do. 4 can be discussed however not all of us have Macs (i don't) so it is hard for me to test and to see if your proposed implementation would be acceptable without time (i have access to one occasionally).

[hmaarrfk]

Others may have other opinions. But I think that at the very least, forking can be a good way to say: "see these are the specific changes I am requesting upstream"

[Adamtaranto]

I'd be happy to work on some of these. Also, to clarify, I'm suggesting adding an additional release option separate to what already exists.

1. I agree with you re generally avoiding adding things to the base env, this would be in a separate release.

2. Not suggesting adding VSCode to the installer, just the package ipykernel that is required to render notebooks.

3. Running conda init bash in miniforge prompt actually does currently create a ~/.bash_profile and add miniforge. At least on Windows machines.

4. Cool! I'll check it out.

As an alternative to having a separate release, would it be compatible with the current miniforge philosophy to add these options to the installer?

• Opt to add miniforge to .bashrc (or whatever conda init bash does)
• Providing path to an alternative construct.yaml for setting up the base env

If we have those I can write my own wrapper.

[hmaarrfk]

1. I understand what you are asking, but beyond the "first time installation of python", this is of very limited utility in my experience.
2. again, this is super easy if you fork and call it something like CondaCarpenter (your seems to have a good branding style so you can think of something smarter).
3. Ah i forgot about windows. Yeah again, I don't even use windows on a daily basis ;). .bash_profile might be used there.
4. Thanks!

Again, I think 1-3 are very hard sells for "miniforge" and adding to our maintenance burden is troublesome. How often do we rerelase? Today it is "every update of conda", but if we add more subpackages then what does that do? I've been stuck releasing a deprecation warning for 2 weeks.... #655

In today's world, more questions have to be asked: Do you install numpy 1.26 or numpy 2.1? The same will happen for pandas 3.

These are very hard for conda-forge to answer, but likely very easy for you to answer in your fork.

If we have those I can write my own wrapper.

Miniforge is already a very thin wrapper over https://github.com/conda/constructor/

We basically have:

1. A construct.yaml file
2. Some CI building https://github.com/conda-forge/miniforge/blob/main/scripts/build.sh
3. Some CI testing https://github.com/conda-forge/miniforge/blob/main/scripts/test.sh
4. Some CI uploads https://github.com/conda-forge/miniforge/blob/main/.github/workflows/ci.yml

Most of our tests have been added to answer user questions regarding compatibility.
You can fork/inspire yourself to take what you need. Its OSS anyway.

You have a very specific mission to make "data science easy to install". its somewhat orthogonal to "helping users install the specific version of software they want".

[Adamtaranto]

Fair enough, I see your point about not wanting to have to curate versions of random other packages installed alongside a miniforge release.

I think there is however a shared interest here in making "miniforge easy to install".

The biggest conceptual speed bumps that we've seen students run into when installing miniforge are:
A) Executing the bash script for installing on Mac
B) Needing to run conda init bash in the "miniforge prompt" before being able to use conda in a regular bash shell (i.e GitBash shell on Windows)

It seems that A is being solved in #434.

B is only really an issue in the windows installer as the OSX installer scripts actually do ask the user if they want to add the # >>> conda initialize >>> block into their bash profile / rc file.

I would like to add a similar option into the windows installer to make it consistent with the OSX process.

Is that something you would be open to incorporating? If so I'll open a new issue to work on it.

[hmaarrfk]

#434 hasn’t had a lot of activity in a while so it might need some help.

On the windows side. Please read #599 (but please don’t reply to it)

Instead get involved in helping the many “windows” windows issues. You will see that tradeoffs exist and even well intentioned solutions can have dangerous consequences.

I use miniforge to great effect on windows Linux and Mac. Learning how to use a terminal or repl is part of the learning curve.

We may benefit from improved documentation with screeenshots for the windows click through. A PR would be appreciated for our website.

All these are great ways to get involved.

[jaimergp]

FYI, constructor supports shipping extra environments in addition to base. This would be a good way (in the Carpentry installer) to add extra stuff to the installer without compromising base. See https://conda.github.io/constructor/construct-yaml/#extra-envs.