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

Exclude candidates in get_dependencies of the DependencyProvider #14

Closed
tdejager opened this issue Jan 23, 2024 · 3 comments · Fixed by #17
Closed

Exclude candidates in get_dependencies of the DependencyProvider #14

tdejager opened this issue Jan 23, 2024 · 3 comments · Fixed by #17

Comments

@tdejager
Copy link
Contributor

Description

It would be a really nice feature if we have a way to exclude candidates when getting their dependencies.
With pypi packages for example it's possible that you are able to get the candidates for a Solvable but that it is impossible to get the dependencies for this candidate.

With pypi packages, specifically in the case of source distributions, you might not be able to get the metadata because you have to build the source, which might fail. It would be nice to be able to exclude this candidate at this point.

However, we would need to think how to best handle this, as backtracking might not be interesting. Take the case where you want to have pygame as a dependency for example, this depends on sdl2, should this source build fail because sdl2 is missing. Backtracking will take long (because it has to build everything) and would not produce any good results. I think aborting the solve in this case would be best. However, there might be situations where an older build would work, idk, maybe backtracking does make sense.

Prior art

When looking at pubgrub, specifically: https://github.com/pubgrub-rs/pubgrub/blob/717289be5722dd5caaa0d1f4ed13047d11a7f7fd/src/solver.rs#L141C8-L153C21

It seems there are 2 options for get_dependencies, there is a Result that makes the solver abort the current resolution. But also a Dependencies::Unknown enum that adds an incompatibility to the solver.

@wolfv
Copy link
Member

wolfv commented Jan 24, 2024

I think regarding the backtracking – it should generally always make sense to test more versions. The main thing is that we need to provide a good UI / UX to the user so that they would see exactly the error (I think pip also shows it during the resolving).

Then the user could cancel the testing of more versions by using CTRL+C and specify a different version of pygame / SDL2 / etc.

On the other hand, it could be interesting to add a 'stop' function to resolvo (e.g. by timeout or by some other condition that the developer could implement). resolvo could call that function at every iteration and stop iterating if it evaluates to true (but IMO that's another issue #8).

@wolfv
Copy link
Member

wolfv commented Jan 24, 2024

To expand a bit on this issue and provide some more context: in the DependencyProvider we return the Dependencies, but not a Result or enum. So we have no way to bubble up some problem if none of the dependencies can be used.

Here is the code in rip that causes a panic! that we would love to get rid of:

https://github.com/prefix-dev/rip/blob/25e2344e62804dab039a1c806b7489c3779f3e47/crates/rattler_installs_packages/src/resolve/dependency_provider.rs#L466-L479

@tdejager
Copy link
Contributor Author

I agree with Wolf I do think the API that is offered by pubgrub-rs is pretty good to start off with. Stop in case of Error in Result and something like the Unknown which continues backtracking.

tdejager pushed a commit that referenced this issue Jan 25, 2024
Adds the ability to return `UnknownDependencies` in `get_dependencies` this way the `Solvable` is excluded from the solution set.

Closes #14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants