Add support for pre-releases in Python version requests

[zanieb]

e.g. now that we have #7263 we supply a release candidate but we don't support --python 3.13rc2 (that's parsed as an executable name)

[mikeleppane]

Hi. I'm checking this out.

Question: Should we only focus on release candidates or also on alpha and beta releases?

[zanieb]

Sweet.

I think we should support all the prerelease kinds. We have a type for this at pep440::version::Prerelease.

There's a bit of structure design work here too. VersionRequest is currently defined as:

pub enum VersionRequest {
    #[default]
    Any,
    Major(u8),
    MajorMinor(u8, u8),
    MajorMinorPatch(u8, u8, u8),
    Range(VersionSpecifiers),
}

I think we'll want to add an Option<Prerelease> to the Major, MajorMinor, and MajorMinorPatch variants (as opposed to introducing new variants like MajorPrerelease), but I'm not sure if that's the best way to do it without trying.

[mikeleppane]

Okay, great! Something along those lines I already managed to discover.

I think we'll want to add an Option to the Major, MajorMinor, and MajorMinorPatch variants (as opposed to introducing new variants like MajorPrerelease), but I'm not sure if that's the best way to do it without trying.

Yeah, let's see which one is the best solution.

To clarify, these are the prerelease variants that need to be covered (according to PEP 440):

X.YaN   # Alpha release
X.YbN   # Beta release
X.YrcN  # Release Candidate

Regarding the variants, if we introduce a new variant, will only one suffice, like MajorMinorPrerelease? Or is there a use case for Major(u8, Option<Prerelease>)?

[zanieb]

Hm. 3.13rc2 seems valid as well as 3.13.0rc2. In the first, the 0 is implied. In contrast, 3.13.1rc1 seems wrong as does 3rc2. So maybe we do just want MajorMinorPrerelease. I wonder if we should support 3.13rc and select the latest release candidate? Or generally support requesting whatever pre-release is available?

Note I made some changes around pre-releases in #7290 and #7300