Question: Is it possible to convert from a explicit lockfile to a unified lockfile?

[matthewfeickert]

Is it possible to convert from a explicit lockfile to a unified lockfile? I believe the answer to this is "no", but given the response to Issue #178 I wasn't sure if there was some undocumented way to do so (given that conversion is not mentioned in the docs at all).

This question has similar motivations to Issue #780, given that with Pixi you can use the

pixi workspace export conda-explicit-spec

CLI to export the environments as conda explicit spec files, which seem to be(?) the exact same format as conda-lock explicit lock files, other than sorting differences(?).

While the semantics of

conda create --name <name> --file <conda spec file/conda-lock explicit lock file>

are fine, there are certain workflows that are expecting a format of either an environment.yml environment definition file or a conda-lock.yml unified lockfile (example: repo2docker, c.f. jupyterhub/repo2docker#1339) and so I wasn't sure if there was any conversion story at this point.

[maresb]

Hey @matthewfeickert, interesting question!

I don't think it makes much sense to convert from an explicit lockfile to a unified lockfile, primarily for the reason that the unified lockfile is designed to include lots of extra metadata that's not present in an explicit lockfile.

The sort ordering is a salient point. Explicit lockfiles should be sorted in a "topological ordering" meaning that each package should precede each of its dependencies. Such an ordering is very much not unique, although there is one particularly nice standard ordering: alternate between collecting all packages whose dependencies have all been satisfied, and then outputting that group in alphabetical order. (Have you noticed any discrepancies between conda-lock and conda explicit lockfiles? Conda-lock uses the vendored toposort function from conda, so I'd be surprised if there were significant differences.)

One fundamental problem with going from explicit lockfiles to unified lockfiles is that explicit lockfiles omit the dependency information, and unified lockfiles don't have any meaningful notion of ordering, so it would be impossible to round-trip from explicit to unified to explicit while guaranteeing the topological ordering. I suppose you could hack it so that you construct a unified lockfile where each package depends on its predecessor in the original explicit lockfile, but then that dependency metadata in the unified lockfile is a lie.

So if you had some pipeline that generated a unified lockfile as an intermediate step, and if that intermediate lockfile had no risk of confusing a human, then I don't think it would be hard to hack something together.