feat: implement pypi pre-release support#4984
Conversation
| let channel = package_db.into_channel().await.unwrap(); | ||
| let channel_url = channel.url(); | ||
|
|
||
| // With prerelease-mode = "allow", the resolver should pick the pre-release 2.0.0a1 |
There was a problem hiding this comment.
Do you think it makes sense to have a first test where we don't set any prerelease modes, and expect to get a simple 1.0.0 version?
There was a problem hiding this comment.
Other tests would've failed 🙂 But we could if you want :) Does the test_prerelease_mode dissallow cover enough? Would we not be testing uv functionality basically otherwise?
| )] | ||
| #[strum(serialize_all = "kebab-case")] | ||
| #[serde(rename_all = "kebab-case")] | ||
| pub enum PrereleaseMode { |
There was a problem hiding this comment.
could we import this type from rattler-lock? or we declare a new one to create macros over it?
There was a problem hiding this comment.
Yeah I tried this but because that crate is optional this essentially makes rattler_lock required for these versions. This is the way we are handling this for other types as well, so makes sense to keep it for this? Wdyt? Also, in this case a macro would duplicate with just an abstraction I'd say.
Description
This exposes the uv pre-release config so that can allow for them even if they are not explicitly specified.
See the issue that this fixes for some motivation.
Fixes #1291
How Has This Been Tested?
There are some automated tests, one of which creates an integration test that creates an pre-release that should be selected.
Tested that this selects the
devhttpx version.AI Disclosure
Clause Opus 4.5
Checklist:
schema/model.py.Draft status
We need a
rattler_lockupdate to save the pre-release flag per environment. This is here: conda/rattler#1889