-
Notifications
You must be signed in to change notification settings - Fork 13
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
Exposing a way to interpret and treat Solver diagnostics #30
Comments
You could probably just expose the underlying type provided by 0install, which organises things by package and has more structure: |
Sounds good, would you accept a PR adding this? |
Hmm it seems that simply exposing the underlying type won't exactly do since the actual type diagnostics = Input.requirements which if I made no mistake is `Zeroinstall_solver.S.CORE_MODEL.requirements. The |
Ah, yes. The diagnostics are calculated lazily. |
Sorry for the delay, I had a few other things to deal with first but I'm getting back to this as being able to inpertret the solver's result when there's no solution is proving more and more important for opam-monorepo! I'll open a PR shortly and we can discuss the specifics there instead! |
It seems that the
Solver.diagnostics
is currently unexposed and the only API entry that allows dealing with this type is the eponymous function which simply returns it as a single string.Is there something I could use to be able to programmatically inspect solver errors? If not would you be willing to add such a thing?
That would prove quite helpful for opam-monorepo, in particular to help with tarides/opam-monorepo#168 where we want to provide suggestions based on why the solving failed.
We could hack something by looking for a specific substring but I could settle for a cleaner solution!
The text was updated successfully, but these errors were encountered: