-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better missing version error #248
Better missing version error #248
Conversation
80311ff
to
ec87109
Compare
With @NathanReb's very valuable hint that I can get the rejection condition from |
0dbffdd
to
e93736e
Compare
Do you think we could extract a test for this? That would also help seeing what the output looks like! |
Yes, that's definitely the idea! Which is why I rebased on |
e93736e
to
61c89d0
Compare
This has the advantage that it will not fail when there aren't any FailsRestriction rejections.
61c89d0
to
a0cf396
Compare
9c8546f
to
09a0c06
Compare
Thanks to @emillon for helping me debug this behavior of grep. Which is somewhat understandable (given grep adds a \n and with -z it is a \0) but extremely unhelpful.
So I think this is ready for review. Adding these cram tests is quite rewarding and reasonably easy so I think overall they're a big win in documenting the behavior and making sure it doesn't get broken (and if it does, we will know about it). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, thanks!
I have a few comments code-wise.
I also think we should add a regression test for the original issue, the one with no dune compatible versions as well. That is, if for a package, no version build with dune and no version match the constraint, only the latter is reported.
Also looking at the output, I think we should consider dropping the base diagnosis if we find such packages or packages that don't build with dune. We can do this in a separate PR but I'm curious to know what you think about such an approach! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did another quick pass as I thought you already made some changes. I think I was a little early to the party but I think I found some nice improvements we could make nonetheless!
Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much better, thanks! I have a few minor comments but once they're fixed this is good to go!
Co-authored-by: Nathan Rebours <nathan.p.rebours@gmail.com>
Co-authored-by: Nathan Rebours <nathan.p.rebours@gmail.com>
127a98b
to
4a9621c
Compare
CHANGES: ### Added - Add opam extensions `x-opam-monorepo-opam-repositories` and `x-opam-monorepo-global-opam-vars` to make `lock` fully reproducible. (tarides/opam-monorepo#250, tarides/opam-monorepo#253, @NathanReb) - Show an error message when the solver can't find any version that satisfies the requested version constraint in the user's OPAM file (tarides/opam-monorepo#215, tarides/opam-monorepo#248, @Leonidas-from-XIV) - Allow packages to be marked as being provided by Opam and not to be pulled by `opam-monorepo`. To control this a new optional Opam file field, `x-opam-monorepo-opam-provided` is introduced. Its value is a list of package names that are to be excluded from being pulled (tarides/opam-monorepo#234, @Leonidas-from-XIV) - Show an error message when the OCaml version of the lock file does not match the OCaml version of the switch (tarides/opam-monorepo#267, tarides/opam-monorepo#268, @Leonidas-from-XIV) - Generate a `duniverse/README.md` file to explain the basics of `opam-monorepo` in the vendored directory (tarides/opam-monorepo#272, tarides/opam-monorepo#274, @Leonidas-from-XIV) - Add a `--prefer-cross-compile` flag for the solver to select cross-compiling versions of packages when available. This is determined through the presence of the `"cross-compile"` tag in the opam metadata. ### Changed - Bump lockfile version to 0.3 (tarides/opam-monorepo#285, @NathanReb) - Mark packages to be pulled by opam-monorepo with the `vendor` variable so using OPAM with `opam install --deps-only --locked .` will not install packages that will be installed with `opam-monorepo pull` (tarides/opam-monorepo#237, @Leonidas-from-XIV) ### Deprecated ### Fixed - Fix a bug where a package which had a single version that built with dune and got selected by the solver would be reported has having no version building with dune. (tarides/opam-monorepo#245, @Leonidas-from-XIV) - Fix the solver so it does not select beta versions of the compiler unless forced to by version constraints or `--ocaml-version`. (tarides/opam-monorepo#269, @NathanReb) ### Removed - Drop support for lockfile versions 0.2 and lower (tarides/opam-monorepo#285, @NathanReb) ### Security
CHANGES: ### Added - Add opam extensions `x-opam-monorepo-opam-repositories` and `x-opam-monorepo-global-opam-vars` to make `lock` fully reproducible. (tarides/opam-monorepo#250, tarides/opam-monorepo#253, @NathanReb) - Show an error message when the solver can't find any version that satisfies the requested version constraint in the user's OPAM file (tarides/opam-monorepo#215, tarides/opam-monorepo#248, tarides/opam-monorepo#290 @Leonidas-from-XIV) - Allow packages to be marked as being provided by Opam and not to be pulled by `opam-monorepo`. To control this a new optional Opam file field, `x-opam-monorepo-opam-provided` is introduced. Its value is a list of package names that are to be excluded from being pulled (tarides/opam-monorepo#234, @Leonidas-from-XIV) - Show an error message when the OCaml version of the lock file does not match the OCaml version of the switch (tarides/opam-monorepo#267, tarides/opam-monorepo#268, @Leonidas-from-XIV) - Generate a `duniverse/README.md` file to explain the basics of `opam-monorepo` in the vendored directory (tarides/opam-monorepo#272, tarides/opam-monorepo#274, @Leonidas-from-XIV) - Add a `--prefer-cross-compile` flag for the solver to select cross-compiling versions of packages when available. This is determined through the presence of the `"cross-compile"` tag in the opam metadata. ### Changed - Bump lockfile version to 0.3 (tarides/opam-monorepo#285, @NathanReb) - Mark packages to be pulled by opam-monorepo with the `vendor` variable so using OPAM with `opam install --deps-only --locked .` will not install packages that will be installed with `opam-monorepo pull` (tarides/opam-monorepo#237, @Leonidas-from-XIV) ### Fixed - Fix a bug where a package which had a single version that built with dune and got selected by the solver would be reported has having no version building with dune. (tarides/opam-monorepo#245, @Leonidas-from-XIV) - Fix the solver so it does not select beta versions of the compiler unless forced to by version constraints or `--ocaml-version`. (tarides/opam-monorepo#269, @NathanReb) ### Removed - Drop support for lockfile versions 0.2 and lower (tarides/opam-monorepo#285, @NathanReb)
I've continued to play around with what info can be retrieved from the map and with a bit of squinting (extracting the version restriction from another rejection case) I was able to test the version check on the packages that we exclude as not building with dune.
If I specify
fmt {>= "1.0.0"}
in myopam
file I get this error message now:It is somewhat involved and hairy so I am not entirely sure whether this is worth it so I'm opening this PR as a draft, more of an RFC to see if we even want to do stuff this way or whether we should patch the 0install solver to expose better information instead.
Closes #215