Swap out Miniconda for Miniforge as the conda package manager

[millsks]

Edit: Updated the title of the issue from Miniconda is not free for commercial use.

I wanted to propose switching out Miniconda for Miniforge. The Miniconda installer, while free for open source projects, to an extent, it has not been free for commercial use since about 2020.

By default, Miniconda downloads packages from the official Anaconda channel. This channel offers a curated selection of packages that are compatible with each other and tested by Anaconda. However, this channel is not free for commercial use. You can add other channels to access a wider variety of packages. Some popular channels include conda-forge and bioconda, but it still stands that the initial set of packages came from Anaconda's software channel.

If Miniforge were to replace Miniconda as the conda package manager included in CF's python buildpack teams that support cloud foundry commercially, it would not have to restrict development teams to only part of what the buildpack is capable of. The conda package manager would be installed and it would get the packages for the base environment from conda-forge instead of Anaconda's software channel.

The conda package manager becomes critical when it comes to supporting data science and machine learning projects. At this point, DevOps teams would have to create one-off buildpacks to either remove Miniconda to guarantee they don't get hit with licensing costs and/or replace Miniconda with Minforge themselves. It would be ideal if this enhancement came from CF so that we are using a product that developed and tested at the source of distribution.

https://www.anaconda.com/blog/is-conda-free

https://community.anaconda.cloud/t/do-i-still-need-miniforge/42591/2

https://legal.anaconda.com/policies/en/?name=terms-of-service

[robdimsdale]

hey @millsks

Thanks for reaching out. Your understanding is broadly consistent with ours, that commercial customers of miniconda (and hence the python buildpack) will need to understand and be mindful of the ramifications of miniconda's licensing.

It is my understanding that if we switch to miniforce we would prevent users from using the conda channel at all. While that makes it convenient for consumers who know for sure they wouldn't want to use packages from that channel (presumably, you), it prevents other users from potentially using the conda channel for any package, even if they are willing and able to work with those pacakges' licenses.

So to paraphrase your request, you're asking us to remove the capability for anyone and everyone to use packages from the conda channel, in order to make it more convenient to ensure that some subset of users don't accidentally use packages from the conda channel.

I think this is a big ask, so I just want to make sure I understand it correctly. Are there not other ways to prevent end-users from requring packages from the conda channel? E.g. networking deny-lists, miniconda config, etc?

As an aside, if you are a commercial customer of a Cloud Foundry vendor, I would encourage you to raise these kinds of asks through your commercial supplier.

[robdimsdale]

Possibly also of interest: https://github.com/orgs/paketo-buildpacks/discussions/231

[wayne]

How about a flag to switch off the feature dependency? 🤔

[millsks]

hey @millsks

Thanks for reaching out. Your understanding is broadly consistent with ours, that commercial customers of miniconda (and hence the python buildpack) will need to understand and be mindful of the ramifications of miniconda's licensing.

It is my understanding that if we switch to miniforce we would prevent users from using the conda channel at all. While that makes it convenient for consumers who know for sure they wouldn't want to use packages from that channel (presumably, you), it prevents other users from potentially using the conda channel for any package, even if they are willing and able to work with those pacakges' licenses.

So to paraphrase your request, you're asking us to remove the capability for anyone and everyone to use packages from the conda channel, in order to make it more convenient to ensure that some subset of users don't accidentally use packages from the conda channel.

I think this is a big ask, so I just want to make sure I understand it correctly. Are there not other ways to prevent end-users from requring packages from the conda channel? E.g. networking deny-lists, miniconda config, etc?

As an aside, if you are a commercial customer of a Cloud Foundry vendor, I would encourage you to raise these kinds of asks through your commercial supplier.

Hi @robdimsdale. Sorry it took so long to respond to this. I don't know if I read your reply wrong, but I wasn't looking to remove conda capabilities in its entirety. I was only looking to swap out miniconda for miniforge in order to avoid the licensing issues if your company was larger than 200 people.

The miniforge option comes with the conda-forge channel configured by default, but if the end user still requires packages from the anaconda channels they can always configure their environment file to pull from that channel. Yes, we can technically do the same thing in reverse, but its the fact that the base environment that comes with miniconda would have been originally downloaded from the anaconda channel?

In summary, keep all functionality in the current python buildpack, but swap out the conda package manager for the open-source version from conda-forge.

[sophiewigmore]

I think this was taken care of in some capacity here - https://github.com/cloudfoundry/python-buildpack/commit/a05e460681d9b585170e876fdde23c3128822300 and released in https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.8.29 @ForestEckhardt @millsks @robdimsdale

[millsks]

Thanks for pointing this out @sophiewigmore!

[millsks]

Was just looking at https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.8.29 and the release notes need to be updated to show miniforge3-py312 instead of miniconda3-py39? I opened up https://github.com/cloudfoundry/python-buildpack/issues/982 to see if someone could look into that.

[millsks]

Since this Miniforge was added to the buildpack in #974 we should be able to close this issue.