Warn on managed prerelease interpreters when a stable build is available

[terror]

Resolves #16616

This PR detects managed prerelease interpreters during discovery and warns when a matching stable build is available, wiring the new helper into PythonInstallation::find, find_best, and find_or_download.

[zanieb]

any vs default have different semantics, should we omit it in those cases?

[terror]

Hmm, we are omitting them here right (i.e. !matches)? My understanding is we'd like to surface only the segments a user explicitly set, and these both represent (afaik) no explicit version constraint.

[zanieb]

Sorry, I meant "should we be omitting it"

That's fair. I think I'd expect those to be filtered in the unset_defaults method instead though?

It's a possible foot gun, in the sense that they have different semantics so omitting them could have a different result, but I can't really think of a concrete situation where this would occur. Emitting any would probably mess up the key parser anyway? :/ I'm fine omitting them until there's a problem.

[terror]

That's fair. I think I'd expect those to be filtered in the unset_defaults method instead though?

Yeah agreed, I think simplified_display should be simple in that it just filters out None values.

It's a possible foot gun, in the sense that they have different semantics so omitting them could have a different result, but I can't really think of a concrete situation where this would occur. Emitting any would probably mess up the key parser anyway? :/ I'm fine omitting them until there's a problem.

Looks like omitting anything will screw up the key parser (it expects 5 components), but since what we pass into uv python upgrade doesn't go through the key parsing flow, I think it's fine? 🤔 Especially sine omitting any/default here doesn't have any semantic loss, but I understand how if we use this for some other purpose there could be issues.

[zanieb]

Just as a note

Looks like omitting anything will screw up the key parser (it expects 5 components),

I was referring to PythonDownloadRequest, which is how a request for a "key" is formed and does support missing components since #14399

since what we pass into uv python upgrade doesn't go through the key parsing flow

It could, e.g., we use the generic parser

uv/crates/uv/src/commands/python/install.rs

Line 262 in caf49f8

.map(|target| PythonRequest::parse(target.as_str()))

uv/crates/uv-python/src/discovery.rs

Lines 1822 to 1824 in 60a811e

	if let Ok(request) = PythonDownloadRequest::from_str(value) {
	return Self::Key(request);
	}

so if you request uv python upgrade 3.14-x86_64 or something that goes through the key parsing flow

[MeitarR]

Hey @terror and @zanieb, it's problematic to not always pass the python_downloads_json_url as it may warn users about versions that are not really available to them, as it does not look at the actual json that they use (if it's configured)

I think it should be passed, or not try to warn at all if python_downloads_json_url is configured

[zanieb]

Thanks, I missed that

[zanieb]

#16711