rhumbaforge? about miniforge

[SylvainCorlay]

I'm not excited about the maintenance burden.

Absolutely. I understand that completely.

Do we add Julia because there's Conda.jl? Do we add Ruby because there's conda.rb?

Yes, I would like there to other similar language installers such as mamba.jl (it is more likely with mamba than conda because libmamba does not require a Python interpreter, and can be used in these projects without too many dependencies.)

I think we want to go with the model of conda-forge/conda-smithy.

That's a good idea, maybe to cookiecutter this a bit more!

[znmeb]

As an R programmer (20 years and counting) I'm pretty much locked into the RStudio / tidyverse / Linux / compile packages from source workflow. I spent a week exploring the conda-forge R universe and discovered that it has its own conventions / opinions and that they conflicted in a few ways with my 20+ years of muscle memory.

These weren't earth-shaking issues, just easily-overcome things like PATH / environment variable settings. But it's a cognitive load / learning curve that takes cycles away from troubleshooting my own code.

If I were a 20+ year Python veteran setting out to learn "enough R to work with R programmers on a team", I'd use this as a way to learn the language. But I don't see the point of a non-Python R-only distribution system as an R programmer - I'm locked in to something that's working well.

[SylvainCorlay]

An interest of getting packages from conda-forge compared to getting them from CRAN is that packages are pre-built, which should make the experience much faster. Also, obviously, a consistent distribution with non-R scientific computing packages that you may require (through R bindings).

In any case, minirhumba is already a thing, and conda-forge already has thousands of R packages. The main question is whether it would be interesting to have a rhumbaforge flavor of miniforge.

[isuruf]

I'm not excited about the maintenance burden. It'll add a whole set of new jobs and where do we stop? Do we add Julia because there's Conda.jl? Do we add Ruby because there's conda.rb?

I think we want to go with the model of conda-forge/conda-smithy. I think minirhumba is a great project and we want to encourage others to build on what miniforge does and delegate the maintenance burden. Adding more and more flavours into one repo is not the conda-forge way of spreading out maintenance between lots of people.