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

Add CEP for frozen environments #99

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

jaimergp
Copy link
Contributor

@jaimergp jaimergp commented Nov 19, 2024

@kenodegard
Copy link
Contributor

Something like this plugin (which uses a $CONDA_PREFIX/.protected file): https://github.com/conda-incubator/conda-protect

@baszalmstra
Copy link
Contributor

I wonder if what you had in mind for pixi itself. I assume it should add the frozen file to the environments it creates to prevent other tools to modify it. But should it also respect environments that have this file and not modify them?

With regard to the base environment, when will the frozen file be added? Will a user, after adding it, always have to pass an override flag?

@jaimergp
Copy link
Contributor Author

Something like this plugin (which uses a $CONDA_PREFIX/.protected file): conda-incubator/conda-protect

Oh yes, I need to add this to the CEP references. It's essentially what conda-protect does, but with some inspiration for EXTERNALLY-MANAGED. I envision that conda-protect could be updated to honor this conda-meta/frozen file.

I assume it should add the frozen file to the environments it creates to prevent other tools to modify it.

Correct.

But should it also respect environments that have this file and not modify them?

Yes. Modifications should only be allowed with some manual override. We are trying to prevent users from shooting themselves in the foot, mostly by accident. But AFAIK, pixi does not really modify foreign environments, does it?

@kenodegard
Copy link
Contributor

I assume it should add the frozen file to the environments it creates to prevent other tools to modify it.

Correct.

Hm should we add a tool field to the JSON spec to indicating which tool froze the env? A timestamp could also be useful?

@jaimergp
Copy link
Contributor Author

Hm should we add a tool field to the JSON spec to indicating which tool froze the env? A timestamp could also be useful?

I was wondering about it but the equivalent PEP was kept deliberately simple. If the tool that froze the environment was to "sign it", then it can do so in the text message. The timestamp can be obtained from the modification time on disk too. I have nothing against adding the keys, but I want to make sure we are not falling into premature optimization with extra keys.

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

Successfully merging this pull request may close these issues.

3 participants