[Distutils] Adding Provides-Extra as an edit to PEP 345

[Erik Bray]

On Mon, Jul 9, 2012 at 4:37 PM, Daniel Holth <dholth at gmail.com> wrote:
>>> 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.

The difference is that setup/build dependencies generally should be
downloaded, extracted, and added to the path before another commands
are run, because the packaging framework allows for the behavior of
built-in commands themselves to be modified, as well as certain
metadata.  The usefulness of this has been discussed in past threads.
See

http://mail.python.org/pipermail/distutils-sig/2012-May/018627.html

and the thread Eric Araujo pointed out at:

https://groups.google.com/forum/?fromgroups#!searchin/the-fellowship-of-the-packaging/setup-requires/the-fellowship-of-the-packaging/KVsDQawfEno/M-ODKx9Ne5YJ

> 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.

I don't have data on the "popularity" of setup_requires--is there some
easy way to find that out without downloading an entire PyPI mirror?

That said, I'm anticipating that it would be very useful for
packaging.  As it is, setup.py files tend to contain a lot of
repetitive boilerplate, especially for non-pure-Python packages.  With
the elimination of setup.py, more packages are going to require setup
hook-script modules to be shipped with their code, and I could see
some of these being highly reusable.

I'm certain this is a useful feature--just not so certain whether it's
desirable needed to modify the Metadata spec to account for it.

In the worst case, I could imagine writing some kind of "bootstrap"
module that can be dropped into a project and used via a setup-hook
that is then possible of downloading other build-time dependencies.
But that's exactly the sort of thing I'm trying to get away from--if I
have to maintain a bootstrap script (or another module containing
setup-hooks, custom commands, etc.) I have to update every project
that uses it every time those scripts are updated.

Erik