-
Notifications
You must be signed in to change notification settings - Fork 194
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
Multi env proposal documentation #584
Multi env proposal documentation #584
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks for the writeup
Co-authored-by: Pavel Zwerschke <[email protected]>
Co-authored-by: Pavel Zwerschke <[email protected]>
Co-authored-by: Pavel Zwerschke <[email protected]>
Edit: Example was added the minute I submitted this! IIUC it is a goal of this proposal to support the "prod subset" use case. However I'm unable to come up with an example how to do it in the proposed syntax. Could someone add an example please? The use case is: Solve a child (eg. prod) environment whose explicit dependencies are a subset of a parent (eg. dev) environment's explicit dependencies, pinning all child packages (explicit and implicit) to the versions in the parent environment. Put another way, to produce the child environment, remove all packages from the parent environment that are not needed for the child environment's explicit (+ implied) dependencies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! I have nothing to add to this proposal :)
Co-authored-by: Pavel Zwerschke <[email protected]>
This is not set in stone, merging this version! 🎉 |
Unless Im stepping on anyones toes Ill start implementing an initial version of this today. |
This proposal came out of a discussion between developers from prefix.dev, QuantCo and Anaconda.
In this discussion we went over multiple use cases and came to the conclusion that this approach would give us a good cover of all use cases we could think of.
This is a design proposal and not a set in stone requirement. We will iterate on the design while implementing it.
Feel free to give feedback!
This will be visible in the documentation website, this is also the best way to read it as I used Mkdocs styling to improve readability. (
pixi run docs
of course 😉 )Ping: @pavelzw @0xbe7a @travishathaway