Handling of Pre-Releases when backtracking?

Packaging
17

Cool. If you think these questions must all be answered unambiguously, you can propose improvements to the spec.

If you want my (very much off the top of my head, I reserve the right to contradict myself without prior notice the next time you ask me!) thoughts:

  • The “version specifiers” spec is about comparing versions to a spec. Everything is at the “which versions from this list match the spec” level. So the answer to your “all packages or just this one” questions is always “just this one”.
  • Same with questions about extras - the spec is about “does X.Y match >=W.Z”, extras are not relevant at that level.
  • Explicitly requested is (IMO) a matter for the tool to decide, and as such, tools may well differ.
  • I can’t see any justification in the spec for the idea that “if the specifier includes a pre-release identifier, pre-releases should be included”. Both pip and the packaging library seems to implement this, but I don’t see any explanation of why. I can only assume it’s considered as “explicitly requested”. Personally, I think this is too subtle, and too much a case of “do what I mean”, not least because it triggers all the questions you asked…
  • I’ve already mentioned on the pip issue that the spec doesn’t cover how things work when multiple specifiers need to be satisfied at once. That’s a spec issue.
  • Backtracking is out of scope for the spec, so it’s a tool issue. Of course tools can document their backtracking behaviour, and even agree to follow the same rules, but it’s not something that this spec covers. (Not all resolvers even backtrack - pip’s legacy resolver didn’t, for example).

But in reality, as I said, I mostly don’t care what the answers are - for me, this has no practical impact, it’s just a theoretical exercise. Someone who is actually affected by how all this works should think about it and make a proposal.

Edit: One further thought on backtracking. Given that this thread is titled “Handling of pre-releases when backtracking”, talk of the spec is somewhat off-topic, as the spec doesn’t cover backtracking. And pip’s backtracking behaviour is an implementation detail that I’d be reluctant to document in any depth as we might change it at any point (possibly even to a resolver that doesn’t backtrack at all). I think we need to be careful to be precise about what we’re discussing, or things will end up even more confused than they currently are… :slightly_smiling_face: