-
Notifications
You must be signed in to change notification settings - Fork 68
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
feat: Add channel priority to solve task and expose to python solve #598
feat: Add channel priority to solve task and expose to python solve #598
Conversation
@@ -96,6 +96,12 @@ impl super::SolverImpl for Solver { | |||
"timeout".to_string() | |||
])); | |||
} | |||
// Could ignore the strict_channel_priority flag here or do something like below maybe? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part I'm not so sure what we'd want the behavior to be, it seems to me that this libsolv code doesn't enforce strict channel priority? If so, we can either ignore the option all together to throw if strict priority is true since that's "not supported"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wolfv Libsolv supports this too right? Can you point to where this is handled in mamba?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. Probably we need to set the priority
on the repository, though? I'll take a look.
@ruben-arts here is my PR that we discussed earlier today, let me know what you think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe conda has more options, @wolfv is that the case? In that case an enum would be nicer.
@@ -96,6 +96,12 @@ impl super::SolverImpl for Solver { | |||
"timeout".to_string() | |||
])); | |||
} | |||
// Could ignore the strict_channel_priority flag here or do something like below maybe? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wolfv Libsolv supports this too right? Can you point to where this is handled in mamba?
@baszalmstra It does look like conda has three options: strict, flexible and disabled https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-channels.html#strict-channel-priority and they default to flexible. Rattler via resolvo is defaulting to strict. I can add an enum but maybe with only two values, strict and disabled for now? And flexible could be added later if needed? And I see there is a flag for strict priority for libsolv that micromamba uses but I'm a bit ignorant to how this would be translated to this code. |
Sounds good! Maybe wolf can help with the libsolv side. |
@baszalmstra @wolfv I thought that I figured out how to pass the flag to libsolv in this commit 54796e7 but it's not failing the test that I added in this commit like resolvo does. It shouldn't be able to solve for that version of |
@baszalmstra @wolfv Sorry for the repeated pings, this is just a fairly important change for our workflows. If we can't resolve why libsolv isn't behaving expectedly with strict channel priority, I can just throw if someone specifies strict when using libsolv? And strict handling could be added later |
crates/rattler_solve/src/lib.rs
Outdated
/// for that package. | ||
Strict, | ||
|
||
/// Conda also has "Flexible" as an option, where packages present in multiple channels |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we shoudl use //
so that these comments do not show up in teh documentation for a feature we don't implement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah sounds good, I only did that cuz with //
it formats the comments right against the disabled comment, but likely more confusing for it to be in the documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just rethinking the naming. Let me take a quick look at libsolv!
/// Flexible, | ||
|
||
/// Packages can be retrieved from any channel as package version takes precedence. | ||
Disabled, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shoudl we call this AllEqual
or NoPriority/NoPriorities
? Just thinking of something that makes it really clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking it was nice to be consistent with conda, but also happy to change to NoPriority
if you prefer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, totally. I am also OK with keeping the naming. Just sometimes I think we have the opportunity to come up with new & improved terminology :)
@@ -96,6 +96,12 @@ impl super::SolverImpl for Solver { | |||
"timeout".to_string() | |||
])); | |||
} | |||
// Could ignore the strict_channel_priority flag here or do something like below maybe? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. Probably we need to set the priority
on the repository, though? I'll take a look.
@BenjaminLowry I made a PR against your branch here: BenjaminLowry#1. It shows how we could set the Libsolv has a |
@wolfv Thanks for the PR, I added logic to assign repo priority values where it's determined by the order of the repodatas passed in where the channel with the first repodata is given the highest priority and it descends from there. This is pre-computed so we don't have to do some arbitrary highest priority value and so if you have 5 channels the first will be given 5 and the last will be given 1 and 0 is still available for lowest priority use. This is now behaving as expected for libsolv with strict and disabled priority, does this implementation seem reasonable? Let me know if I'm not following specific rust-isms as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@baszalmstra I'm assuming you also want @wolfv to give a +1? Or is this good to go |
Yeah since @wolfv has a bunch of open comments I was waiting for his approval as well. 😄 Wolf if you are reading this, can you merge if you are happy with this? |
let repo = ManuallyDrop::new(Repo::new(&pool, channel_name)); | ||
// let repo = ManuallyDrop::new(Repo::new(&pool, channel_name)); | ||
let priority: i32 = if task.channel_priority == ChannelPriority::Strict { | ||
// TODO we need to fill in the correct values here, derived from some channel -> priority map |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These comments are outdated, right?
let channel_name = &repodata.records[0].channel; | ||
|
||
// We dont want to drop the Repo, its stored in the pool anyway. | ||
let repo = ManuallyDrop::new(Repo::new(&pool, channel_name)); | ||
// let repo = ManuallyDrop::new(Repo::new(&pool, channel_name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep or remove?
@wolfv I had removed those comments but not committed the change 🤦 now they're gone! |
@baszalmstra Thanks for already working on a release! I saw that py-rattler was bumped to 0.4.0 yesterday, will we be able to ship this change in a new release of py-rattler soon? |
Sure! I can make another release in the next few days. |
Amazing thanks! |
py-rattler 0.5.0 is on pypi which includes your changes. |
There are use cases where disabling strict channel priority is important and so should have functionality in rattler such that it can be disabled. So I added it as a field of the SolveTask and exposed it as a new parameter (that existed before but was deleted) in py-rattler.