Ah, I see the confusion. No - PEP 643 – Metadata for Package Source Distributions | peps.python.org means that backends just put the expanded dependencies in the PKG-INFO file in the sdist, and tools can pick it up from there.
But equally, you’re right, the new syntax in pyproject.toml will exist in sdists on PyPI, and therefore when that sdist is used to install (because there’s no suitable wheel available, for example) the install process will need to be able to build a wheel from source that uses the new syntax.
However, you would also need to make sure that it’s clear that the dependency group won’t support any runtime dependencies needed to support editable installs (an editable install can “inject” additional dependencies even if the dependencies are declared static). This should be a minor point that will be irrelevant 99.9% of the time, but it’s an illustration of the sorts of edge cases that could be missed if we try to (in effect) write a rule that says “inclusion of runtime dependencies is only supported when it works the way we expect”.
Hardly more private, it’s still in the pyproject.toml that’s available exactly as you describe. Yes, there’s one more step to get to the data, but it’s not hard, and it’s certainly no less accessible than the existing situation.
Do you remember who told you that? I don’t think it would have been me, but it’s possible I got influenced by something in the discussions at the time that I no longer recall. It’s not (as far as I can see) stated in the PEP itself, though.
If it was me, then all I can say is that I’m sorry, and yes, my position has changed.
If it wasn’t me, then my position is that not making it versioned was a mistake, and I missed the fact that this wasn’t discussed in the PEP when I approved it. If this is the situation, I can’t comment for whoever did make that statement (presumably one of the PEP authors?) but I’d be interested to know what the thinking was behind that statement (if they can remember).
But ultimately, there’s not much point in re-hashing the past. We need to learn the lessons, fix things if they need fixing, and move on. I don’t plan on proposing a versioning scheme for pyproject.toml myself, simply because I don’t have the time, but if someone wants to do so, that’s fine.
Oh, absolutely. We’d get a cleaner break (a clear error “this project uses pyproject.toml version 1.1, but we only support version 1.0 and earlier”, for example) but nothing’s going to magically make older tools able to process newer features. So it may be that we can park the question of versioning for this discussion - but we do still need to at least consider how transition would work (and document the transition process in the PEP).
I’d go further, and object to the idea of backends rewriting pyproject.toml in a sdist at all. I view the sdist as being an unchanged copy of files from the original source tree, with additional metadata to allow tools to process the sdist easily.
+1 on this.