opam-monorepo: [ERROR] Solving opam-provided dependencies could not find a solution #364
Comments
I assume that usually this Cmdliner information is filled out via
This wording is from the opam-0install-solver when it prints what the solver issue is. I agree the wording is a bit confusing, it should be "solver has decided upon this version to satisfy the users request". Worse than the wording is that it doesn't really tell you why it has chosen this version.
I feel your frustration. Looking at the output and your OPAM file I am unsure why the opam-0install-solver decided that tyxml.3.0.0 is the version to pick, especially given it doesn't even work on the selected ocaml version. opam-monorepo does (deliberately) very little handpicking because it usually doesn't have the insight on what would be best so apart from very few (mostly build packages). And the more handpicking it does the more it has to catch up with what opam-repository is doing. In general, it's mostly about trying to solve the lines that are labelled
It is because the packages in opam-overlays are updated manually. We had some discussions of extending Daniel's That said I doubt that this is the case, very rarely do packages depend on rather specific new versions of the packages (and for those that do, like fmt, uutf and cmdliner we have reasonably recent dunified releases).
A good question. The OPAM solver for sure does a better job at picking versions and explaining why constraints couldn't be fulfilled. On the other hand, the opam solver hasn't been designed to be used separately from the
Thanks for the list, I think these fall info multiple categories:
These are due to the mismatch of packages named
These are all due to it being impossible to unpack each individual tarball into the duniverse. I started tagging them as such so if we manage to implement a solution in dune (basically Very valid concern. I can't say more than what's already written in the ticket, though, it hasn't moved since. |
|
Thanks for your elaborate answer. It is quite concerning to read from the main maintainer
(and this is not the first time I read something along these lines in this project)
Sounds like the approach taken by "opam monorepo" does not scale very well. Last time I asked, there was some ongoing work (shell scripts or so) on at least figuring out what needs updating in "opam-overlays".
I've still, after months of trying, still no clue about what "opam monorepo" attempts to solve. Sometimes I feel I have a handle on that aspect, but then "opam monorepo" surprises me again. Thus, please don't expect any solution from me. It sounds like all you need is figuring out in a "dune" file which library it belongs to (so, maybe a "grep public_name" is sufficient)? And then deleting all other subdirectories? You picked some specific issues from my list and explained why you think it is as it is. But there are some more issues in the list you didn't talk about, is there any specific reason? #262 #291 #340 #342 |
tmattio
added
the
investigate
So, I try with a mirage 4.3.1 to compile a unikernel https://github.com/mirage/retreat.mirage.io:
Now, due to , I get a huge chunk of output from "opam monorepo" which I have trouble to understand:
If you like to reproduce with only the opam file, please take into consideration the call in the Makefile is:
On Dec 13th at 23:00 UTC there was a successful build with the exact same retreat.mirage.io commit (see https://builds.robur.coop/job/retreat/build/5a87812b-9a34-409c-adf9-e7c1a50e1070/ for details). The only moving part seems to be opam-repository.
Now, what can I do? After some hours, I figured "tyxml" may be related, and if I add a
>= "4.5.0"constraint to tyxml (the most recent release), "opam monorepo" finds a solution. Why is that? Why is uu* not up to date in opam-overlays (is this the underlying problem?)? How can I debug why "opam monorepo" selected some versions? The "tyxml (problem) User requested = 3.0.0" makes me wonder how "opam monorepo" requests versions, and whether it can explain its selection criteria?This is again a very painful experience to use this "opam-monorepo". I try to be patient and supportive for "opam monorepo", but every other day I encounter other trouble that makes this tool very hard to use - instead I spend hours on trying to find workarounds. I still have the feeling that nobody is using "opam monorepo" (apart from mirage 4 forces its usage), or am I really the only one running into such issues?
Would a switch to the normal opam solver fix this issue?
Apart from this issue, major issues I encounter every now and then and try to find workarounds
Is it maybe worth to rethink the approach "opam monorepo" has, and maybe start writing down the exact desired semantics with the above issues in mind (the opam repository is indeed changing over time, and there are multiple opam packages in the same tarball)?
//cc @samoht @avsm
The text was updated successfully, but these errors were encountered: