CI for opam-repository-archive reports a linting error for missing upperbound on dependencies that are not published on opam

[hannesm]

Dear Sir or Madam,

as I mentioned weeks ago, there's an issue with the "opam-repository-archive" CI -- it complains if there's a missing upper bound on a dependency -- even if that dependency does not exist in the opam-repository at all.

A workaround is ocaml/opam-repository-archive@9f37f61 -- but it would be great to have the opam-repository-archive CI in shape where we don't have to work around issues.

[shonfeder]

As I think we discussed previously, the current behavior is not incorrect, per se. The current policy states that for a package to be added to the archive

Any dependencies without upper bounds will have upper bounds added, recording the latest available version of the dependency in the primary repo at the time of archiving.

If "Any dependencies without upper bounds will have upper bounds added", then the CI check is correct flagging an error for dependencies that do not have an upper bound added. However, in the case of dependencies which do not exist in the primary opam repository, the qualification "recording the latest available version of the dependency in the primary repo at the time of archiving" is an improper definite description.

The current requirements do not define what should happen in the case of a dependency which is not published, so the CI check cannot yet be incorrect (or correct) here. The solution, I think, must be to clarify the requirements, so that it is clear what should be done for packages which are to be archived when they have dependencies that are not available in the primary repo. Here are some options:

1. Add the needed package to the primary repo or to the archive.
2. Add a dummy/empty package.
3. Remove the dependency entirely (since, iiuc, this can only occur in case the dependency was optional or an alternate for a published package, or else the package would have been broken, in that it was not generally installable).
4. Add an upper bound (either an arbitrary version or based on finding the latest version of this unpublished dependency).

My initial thought here is that the best option may be (3) or (4), in which case the fix is to be done in the archiving tooling rather than in the CI. In fact, iiuc, (4) is how we are currently dealing with these cases, and maybe this indeed what we should keep doing? In which case, perhaps we should just update the policy to clarify this?

If you can help clarify what the requirements should be here, we can work together to ensure tha all the supporting tooling is correct. But clarifying the requirements on the archiving policy is probably not a matter for this repo? WDYT?

[hannesm]

For me, the most sensible would be "if the dependency does not exist, leave it as is".

[shonfeder]

I had not considered that alternative. But I think this could work. Tho I do have two concerns,

1. For the implementation, this would require the linting to compare both the primary repo and the archive repo, and to cross reference every dependency with existing packages. This is all feasible, but it's a non-trivial extension of the linting, which is currently only looks at a single file in a single repo. Still, if needed, this can be done.
2. In terms of the semantics of this check, I am slightly worried that the changing state of the repo could lead us to some mistake. I could imagine this in two directions: a package which was in the repo at some point is removed when we are doing the linting, and we miss enforcement of the linting check; in the other direction, if a typo is introduced the dependency name during the archiving, we wouldn't be able to differentiate this from a package which was never present.

Neither concern is fatal to this extension of the policy, and I think we can adapt to and/or cope with either. However, thinking this thru I have considered an alternative refinement of the requirement. What do you think of something along these lines?

Any required dependency without upper bounds will have upper bounds added, recording the latest available version of the dependency in the primary repo at the time of archiving.
For alternative dependencies in a disjunction, at least one disjunct dependency must have an upper bound recording the latest available version of the dependency in the primary repo at the time of archiving.

For the implementation of the linting check, we would just need to ensure that at least one dependency in a set of alternates had an upper bound, which would require that at least one of the alternatives have a package in the primary repo. IIUC, any package published in the opam repo should be able to be installed based on dependencies published in the primary repo, so I think this invariant should hold. WDYT?