add test infrastructure for ensuring none of our universal locks can produce a dependency tree with multiple versions of the same package for the same marker environment #5598
Assignees
Comments
BurntSushi
added
internal
BurntSushi
added a commit
that referenced
this issue
Sep 20, 2024
This PR adds some additional sanity checking on resolution graphs to ensure we can never install different versions of the same package into the same environment. I used code similar to this to provoke bugs in the resolver before the release, but it never made it into `main`. Here, we add the error checking to the creation of `ResolutionGraph`, since this is where it's most convenient to access the "full" markers of each distribution. We only report an error when `debug_assertions` are enabled to avoid rendering `uv` *completely* unusuable if a bug were to occur in a production binary. For example, maybe a conflict is detected in a marker environment that isn't actually used. While not ideal, `uv` is still usable for any other marker environment. Closes #5598
BurntSushi
added a commit
that referenced
this issue
Sep 23, 2024
This PR adds some additional sanity checking on resolution graphs to ensure we can never install different versions of the same package into the same environment. I used code similar to this to provoke bugs in the resolver before the release, but it never made it into `main`. Here, we add the error checking to the creation of `ResolutionGraph`, since this is where it's most convenient to access the "full" markers of each distribution. We only report an error when `debug_assertions` are enabled to avoid rendering `uv` *completely* unusuable if a bug were to occur in a production binary. For example, maybe a conflict is detected in a marker environment that isn't actually used. While not ideal, `uv` is still usable for any other marker environment. Closes #5598
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As witnessed in #5597, we have actual test outputs where it's possible to try to install two different versions of the same package for the same marker environment. We should add some kind of test or test helper that asserts that the locks we produce in tests do not suffer from this flaw.
Another interesting idea is to prevent these locks by construction. i.e., We could do this check after generating the lock but before writing it to disk. If it turns out we produced a resolution with more than one version of the same package, we could raise an error. This would be kind of a bummer though in general, because it would effectively be us trying to detect our own bugs. But it might lead to a better user experience.
The text was updated successfully, but these errors were encountered: