[Feature Request] use foo.opam.locked file by default if present

[bikallem]

opam version: 2.1.0~alpha

When opam locked file is present in a repo, we have to specifically opt in to use it, i.e. use the --locked option. It would be a nice user experience improvement if opam used .locked file by defualt and in preference over the corresponding .opam file if present.

[rjbou]

It is possible indeed. It would simplify the locked files workflow, but can complecate usual workflow. If a locked file is present in a repository, to share setup with devs, non-devs users will then need to use a --no-lock option to install using the normal opam file.

[bikallem]

Hi @rjbou,

Thanks for looking into this.

non-devs users will then need to use a --no-lock option to install using the normal opam file.

Wouldn't someone who is installing an opam package from a source dir or git repo be considered a dev user?
If I understand correctly, a normal opam user (as opposed to dev) would install an opam package from a opam repository as opposed to from a source dir.

Just so that I understand correctly, opam lock is mostly for a developer user consumption correct?

Are you open to a PR implementing this functionality?

[AltGr]

My first impression on this was that this seems like a good idea: basically, users who don't know what they are doing will want the --locked, while it's the ones who do who want the --no-lock ; hence the better default is --locked by default.

But it's actually a bit more complicated, since there are a few different cases. If we consider the "local switch" case, closer to npm-like workflow, it's entirely sensible.
But if I am in my global 4.10.0 switch, with many things installed, I certainly don't want opam install . to needlessly downgrade many of my packages to follow the lockfile ; and I might actually have several dev-pinned packages, so they would keep fighting every time.

Now, the obvious answer is "--locked should be the default when using a local switch". It seems a little bit too clever though, in that local state can change the meaning of a command in a way that could, in certain cases, be puzzling — especially since we are speaking about reproducing build environments here.
So at least we should add a [NOTE] in either case, when a lock-file is present and opam automatically chose to use it or not: [NOTE] Lock files found, and this is a local switch: will use them / [NOTE] Not using lock files in a global switch.

In any case, it seems clear that opam switch create . should use lock-files; but then it would be disturbing if opam install . stopped doing so. Maybe the better approach would be to remember which file was used (locked or not), and keep using the same one.