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

feat: Add channel priority to solve task and expose to python solve #598

Merged
merged 13 commits into from
Apr 25, 2024

Conversation

BenjaminLowry
Copy link
Contributor

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.

@BenjaminLowry BenjaminLowry changed the title Add option to disable strict channel priority in solve task feat: Add option to disable strict channel priority in solve task Apr 8, 2024
@@ -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?
Copy link
Contributor Author

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"?

Copy link
Collaborator

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?

Copy link
Contributor

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
Copy link
Contributor Author

@ruben-arts here is my PR that we discussed earlier today, let me know what you think

Copy link
Collaborator

@baszalmstra baszalmstra left a 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?
Copy link
Collaborator

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?

@BenjaminLowry
Copy link
Contributor Author

@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.

@baszalmstra
Copy link
Collaborator

Sounds good! Maybe wolf can help with the libsolv side.

@BenjaminLowry
Copy link
Contributor Author

BenjaminLowry commented Apr 9, 2024

@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 pytorch-cpu since it's only present in the pytorch channel. Am I doing something wrong on the libsolv side? Or maybe libsolv's strict priority isn't as strict somehow? I'm fairly stumped

@BenjaminLowry
Copy link
Contributor Author

@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

/// for that package.
Strict,

/// Conda also has "Flexible" as an option, where packages present in multiple channels
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

@wolfv wolfv left a 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,
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?
Copy link
Contributor

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.

@wolfv
Copy link
Contributor

wolfv commented Apr 15, 2024

@BenjaminLowry I made a PR against your branch here: BenjaminLowry#1. It shows how we could set the priority for libsolv.

Libsolv has a priority and a subpriority integer value. The higher priority should win. We would also need a map or count down the channels and I haven't yet investigated how to do that with the structures at hand.

@BenjaminLowry
Copy link
Contributor Author

@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

Copy link
Collaborator

@baszalmstra baszalmstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@BenjaminLowry BenjaminLowry changed the title feat: Add option to disable strict channel priority in solve task feat: Add channel priority to solve task and expose to python solve Apr 19, 2024
@BenjaminLowry
Copy link
Contributor Author

@baszalmstra I'm assuming you also want @wolfv to give a +1? Or is this good to go

@baszalmstra
Copy link
Collaborator

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
Copy link
Contributor

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));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep or remove?

@BenjaminLowry BenjaminLowry requested a review from wolfv April 25, 2024 12:26
@BenjaminLowry
Copy link
Contributor Author

@wolfv I had removed those comments but not committed the change 🤦 now they're gone!

@wolfv wolfv merged commit 926a876 into conda:main Apr 25, 2024
14 checks passed
@baszalmstra baszalmstra mentioned this pull request Apr 25, 2024
@BenjaminLowry
Copy link
Contributor Author

@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?

@baszalmstra
Copy link
Collaborator

Sure! I can make another release in the next few days.

@BenjaminLowry
Copy link
Contributor Author

Amazing thanks!

@baszalmstra
Copy link
Collaborator

baszalmstra commented Apr 26, 2024

py-rattler 0.5.0 is on pypi which includes your changes.

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 this pull request may close these issues.

3 participants