I expect to see a lot of bugs in packages that require some of their build-time dependencies at run time.
Maybe, but wouldn't that be the developer's problem? setup_requires has the same issue--it does not install the setup requirements into site-packages. Instead it just does an egg install into the source directory and activates it on the path. Outside of future setup.py runs, the setup_requires distributions are not available (you would have to add them to install_requires too if you need them at runtime).
OK, it sounds like this "bug" has been mostly anticipated and taken care of already.
Under a scheme like this one would have to list that dependency under Requires-Dist twice: with and without the 'extra' marker. I might still prefer extending the metadata format to add a Setup-Requires-Dist or the like.
I don't follow. Does anyone build/install packages without also first installing the run-time requirements? Surely Setup-Requires-Dist would have exactly the same problem. It seems like two ways to say exactly the same thing.
Let's just try to focus on getting Metadata 1.2 out the door and implemented before its 8th birthday, preferably during Julython... The only thing I need is to be able to represent the wildly popular "extras" feature in METADATA to benefit from PEP 345 and 376 without rewriting thousands of Python packages. That is all. Save the debate about reserved "extra" names for setup / build / test / doc dependencies for Metadata 1.3.