Skip to content
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

Drastically simplify output when packages are missing in solve #11040

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

ElectreAAS
Copy link
Collaborator

Fixes #10987.
When some packages are missing entirely, we only report that as that seems way more pressing than the wall of info about the state of the solver seen in the issue.

The fix was found while working on #11015, but is independent from it.

@ElectreAAS
Copy link
Collaborator Author

cc @v-gb with this PR the inscrutable wall you had should now be entirely replaced by "The following packages couldn't be found: - unix" 🙂

@v-gb
Copy link

v-gb commented Oct 23, 2024

Thanks, that'd be much more understandable.
The format of the list of missing packages seems a bit weird though. To me, one of these formats would make sense

  The following packages couldn't be found:
  - ocamlformat
  - whatever

  The following packages couldn't be found: ocamlformat, whatever

  The following packages couldn't be found: ocamlformat whatever

but it seems to be (from reading the code, I could be mistaken):

The following packages couldn't be found: - ocamlformat - whatever

@ElectreAAS
Copy link
Collaborator Author

You're right. Should be fixed now.

@Alizter
Copy link
Collaborator

Alizter commented Oct 25, 2024

If we are moving 0install to be our own library, we might as well just drop the messages being created in 0install and only have the data. We can then use our own Pp library to render the messages nicely.

@rgrinberg
Copy link
Member

It might be independent from forking the solver, but I think we should finish forking the solver first. In general, we don't make changes in vendored repos without a lot of extra overhead (update scripts, maintaining commits in separate repos). If you fork the solver, you will avoid doing all that work in this PR.

@Leonidas-from-XIV
Copy link
Collaborator

Now that #11015 is merged this needs to be rebased and then we can proceed.

@ElectreAAS
Copy link
Collaborator Author

Rebased on main!

Copy link
Collaborator

@Leonidas-from-XIV Leonidas-from-XIV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking care of this. Here some comments on the code.

src/opam-0install/lib/solver.ml Outdated Show resolved Hide resolved
src/opam-0install/lib/solver.ml Outdated Show resolved Hide resolved
src/opam-0install/lib/solver.ml Outdated Show resolved Hide resolved
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
@ElectreAAS
Copy link
Collaborator Author

Moving to Pp introduces a fair amount of noise in the form of type t -> type 'tag t to accommodate for Pp's notion of tags that are not used at the moment. We could stylize solver failures further with them. What do you think?

let pp f = function
| UserRequested r -> pf f "User requested %s" (format_restrictions [ r ])
let pp = function
| UserRequested r -> Pp.verbatimf "User requested %s" (format_restrictions [ r ])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pp.textf is preferred for this, otherwise things won't wrap well.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, anywhere you have verbatim replace it with text.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I did initially, but I ended up with this kind of formatting:

Rejected
  candidates:
  bar.0.0.1:
  In
  same
  conflict
  class
  (ccc)
  as
  foo

I expect a fair amount of these messages are wrapped in a vbox at some point, which means that basically all spaces in text are used as line breaks

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That indicates that you have too few boxes around and you have some vboxes that need some more thought. I will give you some help once I've read some of the messages.

;;
end

(** Represents a single interface in the example (failed) selections produced by the solver.
It partitions the implementations into good and bad based (initially) on the split from the
impl_provider. As we explore the example selections, we further filter the candidates. *)
module Component = struct
type rejection_reason =
type 'tag rejection_reason =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
type 'tag rejection_reason =
type 'tag rejection_reason =

No need to do this, the tag will always be Stdune.User_message.Style.t.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit tricky to do, but replace everything with 'tag that you introduced with Stdune.User_message.Style.t. We can look at cleaning up that name at another time using our Import module, but there will be too many conflicts for now. Sometimes there is a _ instead of a 'tag in the interface just so that you are aware. Also any unit Pp.t can be taken as Stdune.User_message.Style.t Pp.t but that seems to only be for debug stuff.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If 'tag is always Stdune.User_message.Style.t, why is it parameterized? We could have a type alias in stdune if it's always the same

Copy link
Collaborator

@Alizter Alizter Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not always the same, sometimes it carries style information like color and italics etc. That's why it is polymorphic everywhere else. For the output of the solver none of this is relevant and we should try to keep types simple rather than making them needlessly polymorphic.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be better now.
I couldn't shadow the long Stdune.User_message.Style.t everywhere, so it spills out a little in dune_pkg, but that seems fine to me

(pp_rolemap ~verbose)
reasons
Pp.verbatim "Can't find all required implementations:"
++ Pp.newline
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a break with a vbox surrounding the Pp so that it is formatted the correct way. You might need a hovbox on the sentence above.

@Alizter
Copy link
Collaborator

Alizter commented Nov 13, 2024

Try something like this:

Pp.vbox (
  Pp.concat
  [ Pp.paragraph "Sentece describing something, but not breaking:"
  ; Pp.enumerate ~f candidates])

The vbox will mean each entry is formatted vertically, and the Pp.paragraph will take care of wrapping text more generally.

Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Signed-off-by: Ambre Austen Suhamy <ambre@tarides.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pkg: inscrutable error when depending on a non-existent package
5 participants