Consider removing unused fields (like content_hash) from lock files
#465
Comments
|
yeah I am fine with this. I think we could try to go through a CEP process for the lockfile at some point, and then maybe conda-lock can align themselves with our format. |
Merged
baszalmstra
added a commit
that referenced
this issue
Jan 23, 2024
This completely refactors the lock-file implementation in `rattler-lock` significantly changing the format. Old lock-files can still be read by the current implementation. The goal of the refactor is to allow multiple environments to be stored in the lock-file as well as significantly simplifying the format itself. See the top-level crate documentation for more information about the design and considerations. @ruben-arts I also added behavior to write packages non-alphabetic but in a more "human-readable" friendly style. > [!NOTE] > This significantly deviates from our previous implementation loosely based on conda-lock. > The code is still able to parse `conda-lock.yml` files! Its just not able to output a compatible conda-lock file. > Note that this has already been the case for a long time but the differences didn't used to be so big. > [!IMPORTANT] > This PR is still in previous because I want to first test out the API in Pixi. Nonetheless, reviews are already welcome! > > I also realize this is a huge change, Id be happy to walk anyone through the code on discord! Closes #465
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I suggest we remove
content_hashand some other metadata fields from our implementation, since we are able to verify that a lock-file satisfies certain requirements without all this information anyway.At the moment
rattler_lockis slowly diverging from conda lock. At this point the two formats are no longer compatible anyway. I expect that in the future we'll diverge further anyway.See conda/conda-lock#432.
The text was updated successfully, but these errors were encountered: