conda / conda-lock

Lightweight lockfile for conda environments
https://conda.github.io/conda-lock/
Other
488 stars 103 forks source link

Alphabetize the lockfile #524

Closed mariusvniekerk closed 10 months ago

mariusvniekerk commented 11 months ago

This should be able to implement lockfile sorting as described in #491 .

We probably want to restrict this to v2 lockfiles only as these lockfiles will behave incorrectly when used with older versions of conda-lock

netlify[bot] commented 11 months ago

Deploy Preview for conda-lock ready!

Name Link
Latest commit bb6c7d15df08381215202d6b494630861a8fa93a
Latest deploy log https://app.netlify.com/sites/conda-lock/deploys/655b3e1e22cf9f000884c5ec
Deploy Preview https://deploy-preview-524--conda-lock.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

maresb commented 11 months ago

We probably want to restrict this to v2 lockfiles only as these lockfiles will behave incorrectly when used with older versions of conda-lock

I looked into this, and my understanding is that doing this for Lockfile V1 would break conda-lock install for v1.0.0 through v1.0.4, but that v1.0.5 is would work thanks to #184.

One might argue that v1.0.5 is a bugfix patch, and that v1 lockfiles are not dependent on ordering. So then the question is if anyone out there has a workflow where conda-lock install is pinned between 1.0.0 and 1.0.4 while conda-lock lock is unpinned?

maresb commented 11 months ago

I want to merge and release this if the resulting lockfiles work with conda-lock >=1.0.5 and micromamba >=1.0.0. Just needs testing.

FelixSchwarz commented 11 months ago

@maresb Could you mention what helpful test would look like? Just create a conda lock file with the code from this PR and check that micromamba creates the expected environment? I think I have micromamba 1.5.0 for example.

maresb commented 11 months ago

I'd be very happy to be convinced otherwise, but I don't see a good way to write an automated test for this.

By testing, I mean to just try it out and make sure things are being installed in the correct order.

mariusvniekerk commented 11 months ago

Technically we can just use sorted lockfile and emit the legacy file and check line order in there?

maresb commented 10 months ago

After quite a bit of experimentation I'm fairly convinced this is safe. I had to use v1.1.0 as a lower version due to #194, but that doesn't have anything to do with the alphabetization.

Once we get a test I think we're good to go.

Probably we just verify topological ordering by iterating through the explicit lockfile. With the original LockFile object in hand, we keep track of all the previously "installed" names, and before any insertion we verify that all the dependencies referenced from the LockFile are previously "installed".