-
Notifications
You must be signed in to change notification settings - Fork 103
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
Create a preliminary internal v2 lockfile schema but enforce v1 #412
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
I'm trying to update my #410 which rebases #390 so that the previous logic is reproduced. It it much trickier than I hoped. It's more of a logic puzzle than I can solve for tonight. My goal would be to adjust #390 so that This way, lockfile conversion would work as follows:
|
I don't like having a broken |
As described in #411, the merge of #389 broke parsing of lockfiles for the
conda-lock install
command due to a schema change.In this PR I create explicit v1 and v2 schema, the v2 being preliminary. The only difference between the two is that v2 omits the
optional
from packages. There is no loss of information thanks to the invariantoptional = category != "main"
. Thus it's easy to convert between v1 and v2, and the corresponding functions are added here.The combination of #389 and this PR should be a pure refactor, as input and output are done exclusively with the v1 schema.
This sets us up to make the schema modifiable, as there are some changes I'd like to make. (RFC coming soon...)
Before I consider this to be closing for #411, I want to add tests for
conda-lock install
. I merged #411 because the tests were green, despite the breakage, so I'd like to avoid this happening in the future.