[Distutils] PEP 426 updated based on last round of discussion

[Nick Coghlan]

On 17 July 2013 21:45, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
> On 17 July 2013 12:10, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> I can't imagine it's practical to auto-install a C compiler
>
> Why not?
>
>> - or even to check for one before building.
>>
>> But I can see it being useful for
>> introspection purposes to know about this type of requirement. (A C compiler
>> could be necessary, or optional for speedups, a particular external library
>> could be needed, etc)
>
> Perhaps instead the installer tool would give you a way to clarify
> that you do have a C compiler and to warn if not.
>
> Alternatively a meta-package could be used to indicate (when
> installed) that a compatible C-compiler is available and then other
> distributions could depend on it for building.
>
>> The data would likely only be as good as what project developers provide,
>> but nevertheless having standard places to record the data could encourage
>> doing so...
>>
>> OTOH, maybe this is metadata 3.0 stuff - I feel like at the moment we need
>> to get what we have now out of the door rather than continually adding extra
>> capabilities.
>
> I wasn't proposing to hold anything up or add new capabilities. I'm
> just trying to see how far these changes go towards making non-pure
> Python software automatically installable. Everything I would want to
> build "build requires" software that is not on pypi.
>
> It would be great if e.g. the instructions for installing Cython on
> Windows could just be "pip install cython" instead of this:
> http://wiki.cython.org/InstallingOnWindows

External dependencies are platform specific, so the task of defining
them has been deliberately left to metadata extensions. Depending on a
Windows exe or MSI, an OS X app bundle, a Fedora/RHEL/EPEL/Suse RPM or
a Debian/Ubuntu DEB are all very different things not easily
accommodated in a cross platform standard.

That said, the new metadata standard does deliberately include a few
pieces intended to make such things easier to define:

1. The extensions concept - using a structured data format like JSON
makes it much easier for platform specific tools (or even pip itself)
to say "declare this metadata, and we will run these commands
automatically"
2. The "direct reference" format as a tool for linking a name with a
specific URL
3. The "install hooks" system for running arbitrary additional
commands post-install (if the installation tool is instructed to allow
that)
4. A more robust mechanism for defining supported platforms
5. The extras system extended across all the different kinds of
dependency (so if you don't want to build optional C accelerators, you
can express that clearly and skip all the associated dependencies)

Essentially, the standard tries to provide a better toolkit for
solving these kinds of problems, without trying to solve them
directly. It's still going to be up to other projects like zc.buildout
and conda to provide a way to package that kind of thing up at least
somewhat neatly.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia