New release for PEP 794 and `packaging.pylock`

[brettcannon]

Issue to suggest we should probably do a release.

[notatallshaw]

I would appreciate a new release, however I have created a situation which I think is a blocker for releasing (rather embarrassing for only having the commit bit for less than 2 weeks).

When I accepted #932 my plan was to follow it up with a PR that fully implemented arbitrary strings for arbitrary equality, which is #954. In implementing #954 I have realized there were some required semantic tweaks compared to #932.

Not wanting to create unnecessary backwards incompatibilities, before the release I think either #954 needs merging or #932 reverting.

I am very happy with the state of #954, but there are some design choices someone else should look over, I have highlighted them in the PR description.

[brettcannon]

No one is clamouring for a release ATM, so I think if you can get #954 merged in the next month (?), then that should be fine instead of reverting #932 .

[notatallshaw]

Thanks to @henryiii and everyone who participated in a side quest on case insensitivity I am no longer blocking as #954 is merged.

[henryiii]

I'm a little worried about the behavior of markers changing due to the changes in how legacy versions are handled with specifiers; it turns out all markers basically rely on legacy versions since they are all typed as versions when an operator (including ==) is used due to a very strange spec choice. "platform_release >= '6'" where {"platform_release": "6.1-foobar"} used to raise an InvalidVersion error, but now it's always False (the spec claims it should be True, since it is supposed to fall back to string comparisons if it is not a valid Version). I'd prefer if the "parse everything as versions" aspect was reduced to just platform_release (and actual versions), but that requires a spec change. If the spec doesn't change, I think we should go ahead and follow the spec for comparisons since we changed the behavior already (#889, but needs a new implementation), and I'd love to update the spec so only versions and platform_release have to do this hoop jumping (#939) - but that needs progress on https://discuss.python.org/t/100287.

Edit: To be clear, this fixes a bunch of open issues and PRs, but it does so by giving a different True/False value than in the current spec.

Anyway, for when it's ready, should we prepare the GHA release process #893? We can set the environment up to require 2 or 3 sign-offs before a release is published.

I'd also really like an RC if everyone is okay making one, there might be enough users where a few people might use dev versions and find issues before a final release.

[notatallshaw]

@henryiii thanks for catching this behavior change, I'll do a review this week.

But from a UX perspective I actually prefer returning False here, it allows packaging consumers to process requirements and future changes can still be made.

If we implement the spec as is and that becomes True, then if the spec changes for it to be False that's a more problematic backwards compatibility issue than going from False to True.

[henryiii]

The thing I'm worried about is that it's arbitrary behavior, and it's different than the spec. Before it threw an error, so you'd know not to rely on it. But now, platform_release >= '6' does not throw an error anymore, it just always returns False if the value isn't a version, which is not what the spec says. The behavior is better in that it's easier to work with if you know what the behavior is, but it's worse because there's no way to know what the (silent) behavior is, as it's not following the spec.

You should always protect platform_release by checking the platform, and without short-circuiting, with it throwing an error, you can't. So the current form is basically unusable. (under 50 examples on all of GitHub), we'd be making it usable but not following the current spec.

I guess there's asymmetry between False and True because not is not supported?

[a-reich]

Is the marker handling issue progressing towards a resolution in this specs PR? Otherwise it seems like if this release is blocked indefinitely, then so seemingly so is pip’s pylock support pypa/pip#13334? if pip wants to use the upstream logic rather than include its own.

[henryiii]

So far, the discussion is all positive, so I will make the PR non-draft tomorrow if no one objects.