Make opam switch export --freeze more permissive

[LasseBlaauwbroek]

When I run opam switch export --freeze while having a package pinned to the local filesystem, I get this error:

[ERROR] my-package is path pinned, it can't be exported with --freeze.

I get that this is not possible, but the fact that this prevents the entire export is unfortunate. I would much prefer that Opam just skips the freeze operation of this particular package. Or otherwise, maybe there can be a --permissive option.

[dra27]

xref #4897

[hannesm]

FWIW, it would be great to not modify the semantics of freeze -- which is crucial for reproducible builds. If the feature request is "to not freeze some random packages", adding a "--ignore-local-pins" may be appropriate.

[dra27]

Yes, the change here would be to add an additional option to control this, not alter --freeze itself (even under CLI versioning, etc.)

[LasseBlaauwbroek]

@hannesm My purpose is actually also reproducible builds. However, I should note that the current semantics of freeze already has reproducibility errors (even if it does not output an error). The reason is that it often resolves a CVS pin to the local filesystem, which is also far from ideal from a reproducibility standpoint (it is still better than a filesystem pin, because the CVS hash is included).

At the end of the day, there is probably nothing that can be done about this, but it may be useful to output a warning whenever the export contains links to the local filesystem.

In the same way, maybe it would be interesting to just allow source-links to raw filesystem locations (of course with warnings all over the place)

[hannesm]

@LasseBlaauwbroek Thanks for your comment. I guess we're mostly on the same page here:

• vcs pin to the local filesystem are just used, instead: should be detected and handled
• path pins to the local filesystem leads to fail behaviour, instead they should be handled

Now, the disagreement seems to be in the "handle":

• warn on these local pins (your favourite)
• fail on these local pins (my favourite)

And indeed, the question is about the default semantics -- as @dra27 suggested there should be a new command-line parameter to change the "handle" above - warn or fail.

NB: of course this still can lead to something not reproducible, since we rely on URLs (and thus DNS) which in certain network setups (e.g. your private company network) may result in different accessible repositories and repositories. But I don't think it is worth to deal with that.

[LasseBlaauwbroek]

I agree with your analysis. My personal reasoning is that I prefer a mostly reproducible build over a not-at-all reproducible build (because opam gave an error). But I can imagine that other situations ask for an error.

So I would propose that we do this:

1. Change the current semantics to also error out when a local-cvs pin is encountered.
2. Add an option --warn that deals gracefully with both local-cvs pins and local-filesystem pins
   The question then remains what it means to gracefully handle local-filesystem pins. Is that filesystem URL substituted for the original source? Is that a feasible thing to do?