Skip to content

Improve resolver error messages referencing workspace members#6066

Closed
zanieb wants to merge 2 commits intomainfrom
zb/resolver-workspace-members
Closed

Improve resolver error messages referencing workspace members#6066
zanieb wants to merge 2 commits intomainfrom
zb/resolver-workspace-members

Conversation

@zanieb
Copy link
Member

@zanieb zanieb commented Aug 13, 2024

No description provided.

@zanieb zanieb added error messages Messaging when something goes wrong preview Experimental behavior labels Aug 13, 2024
@zanieb zanieb changed the title zb/resolver workspace members Improve resolver error messages referencing workspace members Aug 13, 2024
@zanieb
Copy link
Member Author

zanieb commented Aug 13, 2024

Some clear improvements here, but I'm disappointed there's basically no coverage for resolution failures involving workspace members — we'll need to add a bunch more test coverage before this can be merged with confidence.

@zanieb
Copy link
Member Author

zanieb commented Aug 14, 2024

Closing in favor of #6092

@zanieb zanieb closed this Aug 14, 2024
zanieb added a commit that referenced this pull request Aug 15, 2024
An extension of #6090 that replaces #6066.

In brief, 

1. Workspace member names are passed to the resolver for no solution
errors
2. There is a new derivation tree pre-processing step that trims
`NoVersion` incompatibilities for workspace members from the derivation
tree. This avoids showing redundant clauses like `Because only
bird==0.1.0 is available and bird==0.1.0 depends on anyio==4.3.0, we can
conclude that all versions of bird depend on anyio==4.3.0.`. As a minor
note, we use a custom incompatibility kind to mark these
incompatibilities at resolution-time instead of afterwards.
3. Root dependencies on workspace members say `your workspace requires
bird` rather than `you require bird`
4. Workspace member package display omits the version, e.g., `bird`
instead of `bird==0.1.0`
5. Instead of reporting a workspace member as unusable we note that its
requirements cannot be solved, e.g., `bird's requirements are
unsatisfiable` instead of `bird cannot be used`.
6. Instead of saying `your requirements are unsatisfiable` we say `your
workspace's requirements are unsatisfiable` when in a workspace, since
we're not in a "provide direct requirements" paradigm.

As an annoying but minor implementation detail, `PackageRange` now
requires access to the `PubGrubReportFormatter` so it can determine if
it is formatting a workspace member or not. We could probably improve
the abstractions in the future.

As a follow-up, we should additional special casing for "single project"
workspaces to avoid mention of the workspace concept in simple projects.
However, it looks like this will require additional tree manipulations
so I'm going to keep it separate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

error messages Messaging when something goes wrong preview Experimental behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant