How to regenerate mix.lock files at a specific date?

Hello all,

We have an outside vendor which supplied us a source deliverable, but they did not supply us with their mix.lock files. So, we cannot reproduce their build environment using the same package versions that they used, and we want to match their tested versions as much as possible as we integrate their deliverable into our software. Unfortunately, they did not keep these files and will not provide additional releases of this source deliverable, but they can supply their build date. So, I’d like to know if there is any way to generate mix.lock files as if we had built on that earlier date. Any ideas?

Is there a git repo containing all the packages, or similar, so I can checkout at a specific date/time and see the package versions? I think this would be wonderful, if available :slight_smile: Hopefully I can point mix at a local git repo and just hard reset the git repo version to the specified date to go back in time (n.b. this is similar to what we’re doing for missing Cargo.lock files).

BTW - I realize this style of question can lead to many suggestions outside of the mix.lock+fixed date question (e.g. ask the vendor for X, do you really need to match versions, etc.). But, it is very helpful for us if we can focus on this key question, at least for the time being. I hope y’all understand and thanks very much for your help.

Best regards,
Shaun

1 Like

To clarify: which files do you have from the vendor? Did they give you the mix.exs file (but for some reason not mix.lock)?

I’m not aware of any existing automated way to do this, but if you do have the mix.exs file, one thing I can think of is to go to look up each package on Hex. Unless specificed otherwise, this is the default location that deps are pulled from when specified in mix.exs, so this is probably closest to “a git repo containing all of the packages” that you asked about. On Hex you see which version was available on the needed date, and then specify in your mix.exs file the specific version number that was available on that date. Example for the Phoenix package: if the vendor’s mix.exs file says {:phoenix, "~> 1.4"}, and I was looking to rebuild the package using deps from March 1, 2019, I can see that the latest version of Phoenix available on that date was 1.4.1, so in my mix.exs file I specify {:phoenix, "== 1.4.1"}.

If the packages aren’t on Hex and are specific git repos, you could probably do the same thing by looking through the git commits to see which version was committed on certain dates, but this will be a bit more of a pain.

1 Like

You can’t.

If the code has been compiled shortly after a new version of a package has been released which then got yanked during the yank-window, you won’t be able to see that package but an older one.

Also just picking the most recent version of each package at that point in time might give you problems. mix might have choosen some lower versions due to version constraints in the dep-graph.

And actually a date is a span of 24 hours in which can happen a lot. Even if we refuse to accept that packages might have got yanked, still during 24 h a lot of subsequent releases can happen. You need to know the exact build time, but then you’ll have the problem that you do not know when during the day each version got released.

Long story short: Without the lock-file you can not recreate it.

1 Like

Hi NobbZ,

Thanks, this is great info. We expect that we cannot achieve a 100% version match, since packages can change on the same day. But, your breakdown about yanked packages and constraints gives other cases we hadn’t considered, and is very valuable. We will definitely ask the vendor to supply mix.lock files in the future when we need to sync with their environment.

Best regards,
Shaun

Hi xencor,

Yes, we have the mix.exs file. This is a great approach, we will probably do this - thanks. In our case, we have only a short list of packages, so it should be less painful and not require a scripted approach.

Thanks!
Shaun