Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preventing modification of the base environment #636

Open
jaimergp opened this issue Aug 28, 2024 · 4 comments
Open

Preventing modification of the base environment #636

jaimergp opened this issue Aug 28, 2024 · 4 comments

Comments

@jaimergp
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

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

got it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants