[Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)

[Erik Bray]

On Mon, Aug 27, 2012 at 10:56 AM, Daniel Holth <dholth at gmail.com> wrote:
> On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth <dholth at gmail.com> wrote:
>> I've drafted some edits to Metadata 1.2 with valuable feedback from
> ...
>> (full changeset on https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068)
>
> Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is
> it better to continue editing it, or create a new PEP for Metadata
> 1.3?

Somehow I completely overlooked this thread until now.  Thanks Daniel
for getting the ball rolling on this.  There have already been many
bytes spilled on metadata extensions, and although I agree it would be
enormously useful to build an extension mechanism into the metadata
format, I don't have much riding on that, or much more to add that
hasn't been said.

There hasn't been much said about Setup-Requires-Dist, so I'm guessing
it's uncontroversial.  But since that's sort of my hobbyhorse I
thought I would make a comment on it.  The thing I love about the
Setup-Requires-Dist feature is that, if properly supported by
different installers, it can free those installers from a fair bit of
responsibility.

For example, in greatly simplifies the thorny issue of "compilers".
The existing compiler support in distutils, while not without its
problems, does work in most cases for building common C-extensions.
distutils2 has already made some progress on cleaning up the interface
for compilers, and making it easier to register new compiler classes
that can be imported from an arbitrary package.  This allows projects
with special needs (such as Fortran compiler support) to ship their
own compiler class with the project.  Or if there's a good enough
third-party package that provides Fortran compiler support, projects
may use it in their build process.  Support for Setup-Requires-Dist
ensures that a third-party compiler package can be made available at
build-time.

What's great about this, is that even if the stdlib still includes a
build system, it doesn't necessarily have to anticipate every possible
need for building every kind of project (it should, at a minimum, be
able to build pure-Python projects).  If someone wants to add MSVC2012
support they can do that as a third-party package. One could even
create "compilers" for other build systems like waf, or even provide
an entry-point to meta-build systems like bento.  Am I making sense?

Erik