Preventing modification of the `base` environment

[jaimergp]

Most users should not be touching base for much. It should just provide the tooling needed to run conda, mamba and potential plugins.

Here's a suggestion to make this work:

• Keep providing base as we do right now
• Use extra_envs to ship a default environment that ships the same Python and pip used in base
• Configure condarc to activate default instead of base (this might need a change in conda)
• Optional: Install conda-protect in base and block it by default.

Cons:

• Workflows relying on modifications of base (like we do in most of conda-forge CI) would start failing, so we'll need workarounds. Maybe this is done via new options / prompts in constructor, or maybe this is better fixed by using explicit environments in our workflows. Or a separate installer targeting our infra.

I think this approach is more solid than an editable base, and extends well to other applications like "updating the distribution". For example, if Anaconda Distribution was modelled like this (with base + e.g. anaconda-2024.9), getting the new version is just a matter of creating a new anaconda-2025.1 environment and making it the default.

[hmaarrfk]

I've been thinking about this too.

I somewhat feel like it is an anti-pattern for most users to:

1. Provide them with an automatically activated environment with python.
2. Ask them not to modify it.

Maybe it is about adding conda_bin to the path, but not the full environment?

There is ALOT of knowledge base written on the internet about "base" that makes "base" feel like a "default". Not sure how to address that part.

[jaimergp]

Renaming base would need some changes in conda 🤔 And it's also assumed that base is where conda lives. Either way this will need some user re-education. We need to find the smoothest path, but all of them will have some friction at some point.

[jaimergp]

Maybe it is about adding conda_bin to the path, but not the full environment?

That's orthogonal I think. It's not about having conda (the Python entry point) available. When properly initialized, the conda shell function will take care of users having conda available everywhere. The "activate base by default" behaviour is more so the newly installed python is there, along with whatever the installer provided. It will also make it the default argument for --name in conda install|update|remove, etc, and that has nothing to do with whether $PREFIX/condabin is present in PATH or not.

My idea here is that by providing a "new default environment" without conda we:

• Have a fresh environment readily available and ready for modification
• Stop people from adding stuff on top of base that can break conda or prevent its updates
• Allow folks to still use conda ... whenever

[hmaarrfk]

My idea here is that by providing a "new default environment" without conda we:

got it!