-
-
Notifications
You must be signed in to change notification settings - Fork 342
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
Comments
I've been thinking about this too. I somewhat feel like it is an anti-pattern for most users to:
Maybe it is about adding 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. |
Renaming |
That's orthogonal I think. It's not about having My idea here is that by providing a "new default environment" without
|
got it! |
Most users should not be touching
base
for much. It should just provide the tooling needed to runconda
,mamba
and potential plugins.Here's a suggestion to make this work:
base
as we do right nowextra_envs
to ship adefault
environment that ships the same Python andpip
used inbase
default
instead ofbase
(this might need a change inconda
)conda-protect
inbase
and block it by default.Cons:
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 inconstructor
, 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 (withbase
+ e.g.anaconda-2024.9
), getting the new version is just a matter of creating a newanaconda-2025.1
environment and making it the default.The text was updated successfully, but these errors were encountered: