opam monorepo ignores upper bounds #331
Comments
|
Hi @hannesm, thanks for your report. Just came back from a long weekend, so it took a moment to check out the ticket. That is indeed very strange. For a moment I thought that maybe the OPAM metadata is wrong and Also, btw, |
|
FWIW, this was with opam-repository at 46185c6ddabbdb605810a7c2c4f545fe9f92fbfd Also, note that "h2" depends on "hpack" -- which is part of the very same archive (i.e. the h2 release includes the hpack opam file), and indeed h2 0.8.0 works fine with hpack 0.9.0. BUT it seems opam-monorepo is taking some shortcut and throwing away the bound between paf 0.9.0 and h2 < 0.9.0...
I'm sorry I've had no clue that opam-monorepo is special-casing "a small set of other packages". I guess that "ocaml" dependency is introduced by some code inside the mirage utility. |
|
And thanks for your answer @Leonidas-from-XIV! |
|
#145 looks related to this -- maybe this is "expected behaviour", but then I'm not sure what the semantics of version bounds should be, and how to express the situation above (requiring an older h2 to be able to compile paf). |
|
@hannesm Yes, I think this is exactly the case here, opam-monorepo only ever chooses one tarball per repo and if the versions diverge then it can only pick one. The reason for this is, if in unpacks both 0.8.0 and 0.9.0 tarballs you suddenly have two We recently had a case where it would fail because while tarballs often contain all packages of the repo, that package did not so it ended up failing. It seems we need a different solution to this problem because we keep having issues. |
|
I tried reproducing it and turns out that the problem somewhat solved itself because 2 days ago paf 0.1.0 was released, which requires h2 > 0.9.0, so opam-monorepo can use that as a solution. So that should at least unlock your specific problem. Of course if I set the constraint to use force |
|
Is this comment relevant here? opam-monorepo/lib/duniverse.ml Lines 143 to 157 in 9262e7f |
|
Yes that's exactly what is happening here. We need either source trimming or (in my opinion better) a way to enable just certain subtrees for dune to build, basically a way to prune specific packages from the build tree that it discovers. |
Leonidas-from-XIV
added
the
requires dune change
tmattio
added
bug
|
Could it be possible to synthesize constraints for the solver such that all packages with the same dev repo use the same source? Could for example use the url.checksum. |
|
@reynir You mean, solving to get a solution, then resolving conflicts (by picking the higher version of all duplicate packages) and feeding that solution back into the solver to see if it still works? |
|
No, that's not what I mean. I don't know too much about opam-monorepo internals. What I imagine could be done is for h2 and hpack a new virtual package Does this make sense? |
|
This should be fixed by #396 |
|
The issue with @reynir's solution is that the problem is not the deduplication (the deduplication is rather a band-aid to be even able to build these packages at all). The solver is perfectly capable of finding a solution where hpack.0.10.0 and h2.0.9.0 are a valid solution. We can also perfectly well fetch the sources of these. The issue is that it can't be built without a change to dune:
Which one to pick? dune doesn't know and gives up. So if you put them in the duniverse you'll get something like this: And if you manage to make dune ignore the opam files (e.g. by making |
Dear Madam or Sir,
from the following (generated) opam file, the "opam monorepo lock pull" and "dune build" fails. It seems to me that while "hpack 0.9.0" could be used, "h2 0.8.0" must be used (there's an upper bound on "paf 0.9.0" in opam-repository to use "h2 < 0.9.0". Somehow, opam monorepo does not respect this bound -- though pin-depends contains h2 0.8.0, the "duniverse-dirs" only lists "ocaml-h2" with 0.9.0.
Here's the opam file:
Here's the ".lock" file:
The text was updated successfully, but these errors were encountered: