You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally I thought the idea of these installers was mostly for our own use on CI. Do we want to advertise them more broadly? Related to that are we willing to help support people who have issues with the installers?
It is possible that having people use miniforge rather than miniconda will reduce the number of questions we get because of incompatibilities between defaults and conda-forge.
Or it could be an additional source of confusion 😉
Not saying one way or the other which is better. Just trying to point out that listing this in a more public way (or even recommending it), implies we are willing to support this installer. So are we? Also if so, what level of support are we willing to provide? These seem like things we would want to indicate on such a page to help set user expectations.
one of the reasons we didn't advertise it so heavily was that we wanted to maintain favor from those employed full time at Anaconda.
Is there a strong need to advertise miniconda to end users?
I recently released a desktop app, for windows, and I have to say, the Anaconda navigator is pretty good. I had to go down the rabit hole of creating a GUI for my application to get over the "fear of command line".
I think we should advertise miniforge more because of the more platforms it supports as @rgommers said and also because it comes with conda-forge only.
We should discuss this at a core meeting soon. We should also talk about what we want to include, i.e. do we give the user a choice between anaconda/miniconda/miniforge/mambaforge/micromamba or simply miniforge/mambaforge. I would prefer the former as this is the most user-friendly but that definitely needs a very clear wording and a check-in with Anaconda Inc.
We've finally gotten to where we can consider supporting mini/mambaforge more fully on conda-incubator/setup-miniconda#133... I think it's useful enough for in-house stuff to be able to toss miniforge-version and miniforge-variant into something, and have it Just Work (so long as the URL patterns don't change 😿), but if there is concern about not over-hyping the M*forges...
That rapids picker thing is sweeet. However, if under the hood there was really dumb machine-generated DOM (or an at-rest JSON dump) with very predictable/accessible patterns, that would help the above, as that PR uses the GitHub API, which might create problems if I can't figure out how to make it cache properly... to avoid throttling.
Otherwise, in the wild, I know of the this, which appear to be actively supported:
psi4 distribution, in case you want to sling some... you know, quantum chemistry in your spare time.
And these, which I built, and hope to get into a more-automated state, but are a showing their age a bit...
I've also broached the topic a few times with the Jupyter community about doing some "semi-official" curated installers for different learning levels and needs, with a definite focus on "good enough" machines, e.g. RPi, chromebooks, as well as a robust documentation solution.
Perhaps this points to abstracting the "guts" of this repo into its own action... it's a shame it's not easier to call github actions from other actions, but I don't think we want to get into this business on setup-miniconda!
Despite my best efforts, it does seem like my approach for fetching miniforge releases from the GitHub API is starting to get rate-limited on setup-miniconda... having a super-dumb, bare-bones, no-JS static page (maybe not quite as austere as the miniconda one, mind you) would help a lot. It would also be nice if it was a stable URL and never, changed, so maybe this first one would be /all-releases/index.html or something, so that it could soft-launch and add /index.html later.
What's the general feeling now a couple of years later on promoting miniforge? We are planning on making it the recommended way to install Python for sunpy. If that's not a good idea, then that would be good to know. If it is a good idea then would a PR with some nice documentation pages for some install instructions be accepted?
Reacted by Nabil Freij, Ralf Gommers and Nicholas Bollweg
Activity
isuruf commentedon Dec 6, 2020
Yes, please
isuruf commentedon Dec 6, 2020
we can host the docs in this repo's
gh-pagesbranch and then they would appear under https://conda-forge.org/miniforgexhochy commentedon Dec 7, 2020
I really like rapids selector for installations: https://rapids.ai/start.html
xhochy commentedon Dec 7, 2020
Original source for that is from https://github.com/pytorch/pytorch.github.io/blob/9cbd4f3408131e1d2874b410aaed72e7871ae2cd/assets/quick-start-module.js
jakirkham commentedon Dec 7, 2020
Originally I thought the idea of these installers was mostly for our own use on CI. Do we want to advertise them more broadly? Related to that are we willing to help support people who have issues with the installers?
SylvainCorlay commentedon Dec 7, 2020
It is possible that having people use miniforge rather than miniconda will reduce the number of questions we get because of incompatibilities between defaults and conda-forge.
jakirkham commentedon Dec 7, 2020
Or it could be an additional source of confusion 😉
Not saying one way or the other which is better. Just trying to point out that listing this in a more public way (or even recommending it), implies we are willing to support this installer. So are we? Also if so, what level of support are we willing to provide? These seem like things we would want to indicate on such a page to help set user expectations.
rgommers commentedon Dec 7, 2020
I thought that was answered already as "yes, we want to support it publicly". One reason being that Miniforge supports more platforms than Miniconda. See also the mention on https://conda-forge.org/docs/user/introduction.html#how-can-i-install-packages-from-conda-forge.
hmaarrfk commentedon Dec 7, 2020
one of the reasons we didn't advertise it so heavily was that we wanted to maintain favor from those employed full time at Anaconda.
Is there a strong need to advertise miniconda to end users?
I recently released a desktop app, for windows, and I have to say, the Anaconda navigator is pretty good. I had to go down the rabit hole of creating a GUI for my application to get over the "fear of command line".
hmaarrfk commentedon Dec 7, 2020
I personally think that the note in the bottom of the "introduction" is enough.
and that we can elaborate in the README section of this github page.
isuruf commentedon Dec 8, 2020
I think we should advertise miniforge more because of the more platforms it supports as @rgommers said and also because it comes with conda-forge only.
rgommers commentedon Dec 8, 2020
https://numpy.org/install/ does recommend Miniforge already under "advanced users > Linux". I really should add ARM64, and now Mamba.
xhochy commentedon Dec 14, 2020
We should discuss this at a core meeting soon. We should also talk about what we want to include, i.e. do we give the user a choice between anaconda/miniconda/miniforge/mambaforge/micromamba or simply miniforge/mambaforge. I would prefer the former as this is the most user-friendly but that definitely needs a very clear wording and a check-in with Anaconda Inc.
bollwyvl commentedon Dec 28, 2020
We've finally gotten to where we can consider supporting mini/mambaforge more fully on conda-incubator/setup-miniconda#133... I think it's useful enough for in-house stuff to be able to toss
miniforge-versionandminiforge-variantinto something, and have it Just Work (so long as the URL patterns don't change 😿), but if there is concern about not over-hyping the M*forges...That rapids picker thing is sweeet. However, if under the hood there was really dumb machine-generated DOM (or an at-rest JSON dump) with very predictable/accessible patterns, that would help the above, as that PR uses the GitHub API, which might create problems if I can't figure out how to make it cache properly... to avoid throttling.
Otherwise, in the wild, I know of the this, which appear to be actively supported:
And these, which I built, and hope to get into a more-automated state, but are a showing their age a bit...
I've also broached the topic a few times with the Jupyter community about doing some "semi-official" curated installers for different learning levels and needs, with a definite focus on "good enough" machines, e.g. RPi, chromebooks, as well as a robust documentation solution.
Perhaps this points to abstracting the "guts" of this repo into its own action... it's a shame it's not easier to call github actions from other actions, but I don't think we want to get into this business on
setup-miniconda!bollwyvl commentedon Dec 30, 2020
Despite my best efforts, it does seem like my approach for fetching miniforge releases from the GitHub API is starting to get rate-limited on
setup-miniconda... having a super-dumb, bare-bones, no-JS static page (maybe not quite as austere as the miniconda one, mind you) would help a lot. It would also be nice if it was a stable URL and never, changed, so maybe this first one would be/all-releases/index.htmlor something, so that it could soft-launch and add/index.htmllater.I'll hack up something...
bollwyvl commentedon Jan 1, 2021
Here's the hack:
https://nbviewer.jupyter.org/gist/bollwyvl/afb60e57c6f013ff445cfa46385a9b30#Preview
isuruf commentedon Jan 1, 2021
Looks good to me. Can you send a PR with that and then we can iterate on it in the PR
SylvainCorlay commentedon Jan 1, 2021
This looks great. Thanks @bollwyvl !
Cadair commentedon May 12, 2023
What's the general feeling now a couple of years later on promoting miniforge? We are planning on making it the recommended way to install Python for sunpy. If that's not a good idea, then that would be good to know. If it is a good idea then would a PR with some nice documentation pages for some install instructions be accepted?
jaimergp commentedon May 13, 2023
Wow, TIL we have https://conda-forge.org/miniforge 😂
rgommers commentedon May 13, 2023
+1 for doing this, but being even more specific: recommend the Mambaforge flavor. That's certainly what I've been doing (e.g. on https://scipy.org/install/), and using
mambain install instructions rather thanconda.hmaarrfk commentedon Oct 5, 2024
https://conda-forge.org/download/
This now exists.