Request providing a API to generate lockfile for offline build.

[sequencer]

In many build flows, reproducibility and offline building is important.

I wonder if it would be possible to provide a tool from mill to expose all ivy as json as the lock file. Later we can use this file to download all ivy dependencies w/ coursier to prepare the build artifacts for no network building.

A dirty hack has been achieved in our nix flow:
https://github.com/chipsalliance/t1/blob/master/nix/pkgs/mill-builder.nix

[lefou]

Technically, all ivyDeps targets and friends (runIvyDeps, compileIvyDeps) are persisted as json in the Mill cache after a first run. But this is probably not what you had in mind.

So, let me ask, do you already have some specific lock file format in mind, which we should produce? Is there already some lock file format which coursier or nix understands? If not, it would be helpful to gather some information about what we should put in such a file.

The lockfile generator could be implemented as a external module, since all targets providing ivyDeps are more or less introspectable. (The contrib space would be a suitable playground for it.) Once, we have some well established file format, we can think about integrating it directly into the modules that need it (ScalaModule, JavaModule, ...). At that stage, we should even be able fetch/use dependencies directly from persistent lockfiles. This would allow building in other sandbox-like build environments like e.g. portage / Gentoo Linux as well.

[sequencer]

May relate to coursier/coursier#1487

[lefou]

There are two approaches possible:

1. Implement a reasonable serialization format for resolution in coursier, which can be used to fetch and validate later resolutions.
2. Implement the same in Mill directly

Given the comments in coursier/coursier#1487, many parties from different build tools are interested in that feature, and they all have the same motivation for it, so I think approach 1, implementing it in coursier, would be the way forward. OTOH, coursier didn't attract many contributors, so it might be a bit harder to implement it there.