Closed zanieb closed 7 months ago
We talked about this PR in office hours and the plan is to experiment with the larger change to allow adding arbitrary metadata to every user provided incompatibility.
Makes sense that the dependency providers can attach metadata to its responses. These are then useful with custom error reporting, as long as that data is stored and re-shared with the derivation tree.
Makes sense that the dependency providers can attach metadata to its responses. These are then useful with custom error reporting, as long as that data is stored and re-shared with the derivation tree.
That's my plan to explore!
Also another note that Dependencies::Unknown
should probably be renamed to Dependencies::Unavailable
and additional metadata can be used to describe if they are irretrievable (and therefore unknown) or invalid (unusable).
I've made my internal copy public at https://github.com/zanieb/pubgrub/pull/4 so I'll close this one out.
I'll follow-up with some drafts of the discussed changes :)
Adds a new incompatibility kind of unusable dependencies, which is a distinct case from unknown dependencies in that we know the dependencies of the package but we are unwilling to use them.
This incompatibility is useful for some of the cases described in https://github.com/pubgrub-rs/pubgrub/issues/152 allowing versions of a package to be marked as unusable due to a problem in their direct dependencies.
In my fork, I attach a
reason: Option<String>
to theUnusableDependencies
types which allows the resolver to explain why the dependencies are unusable. I have opted not to include that here yet, as I know there is interest in adding such labels to all incompatibility kinds which feels like a separate discussion.