Having some sort of per-project “allow prereleases” option (--allow-pre-for=numpy?) would be a perfectly reasonable thing to offer, and well within the spitit of what even PEP 440 says (i.e., it’s not a “versioning v2” type of change). I think such an option would address these 3 cases.
I can (and probably should) go and look this up myself, but I thought all resolvelib cared about was “does this version satisfy this specifier?” Can you point me at where anything deeper is needed? You’ve worked on resolvelib a lot more recently than I have, so my knowledge could be out of date, but I thought the API was so highly abstracted that pretty much any concept of versions satisfying requirements was sufficient.
Pre-releases are a PITA (as we’re seeing here) because “what matches” is context-dependent in a nasty way. If ease of implementation is the criterion, that context dependency a flaw in the spec - although I’m hesitant about prioritising ease of implementation over user friendliness[1]. This can certainly be solved in a versioning v2.
Extras are an utter abomination, and the way they need to be bolted onto the resolver machinery is a horrific bodge that has no right to exist[2]. That’s a problem with the way the semantics of extras is defined, though, and unrelated to versioning. If I had my way, I’d remove the whole concept of extras - unfortunately they do solve real-world problems and they are very widely used, so even if we replaced them with something better designed, the transition issues would be insurmountable. So we’re stuck with them, unfortunately.
