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

levels of incompatibility #52

Open
StefanKarpinski opened this issue Nov 28, 2017 · 0 comments
Open

levels of incompatibility #52

StefanKarpinski opened this issue Nov 28, 2017 · 0 comments

Comments

@StefanKarpinski
Copy link
Member

Problem: We've had a recent situation where JuliaPro ships with a fixed set of package versions which were compatible at the time it was released, but a subsequent update to METADATA (JuliaLang/METADATA.jl#12106, see discussion in JuliaLang/METADATA.jl#12264) caused that set of versions to become incompatible. Unfortunately, this means that doing almost anything with that set of packages causes the resolver to say that the operation is not allowed because it leads to an incompatible ("infeasible") set of package versions.

Potential solution: In general, it would be good to allow operations that don't make the current situation any worse, and in general to afford users the option to pick their poison in situations where no fully compatible resolution exists. This seems to lead to a notion of "levels of incompatibility" for sets of versions rather than the current black-and-white notion of compatible or not. If you're already at a level of incompatibility, then an operation which doesn't make that level worse should be allowed without warning. If there are no solutions which don't make the situation worse, then it would be ideal to prompt the user with the best options for resolving the situation as well as possible.

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

No branches or pull requests

3 participants