[Distutils] Updated drafts of metadata 2.0 (PEP 426 and PEP 440)

[Nick Coghlan]

On 22 June 2013 00:10, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 June 2013 14:30, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>
>> > Yes, I was thinking more of the sdist side - and also of how a pure
>> > Python package can specify whether separate wheels are needed for Python 2
>> > and Python 3, for example. There's a wheel-specific setup.cfg extension for
>> > this, but should it be in the metadata spec?
>>
>> No, but it should be in the spec/documentation for the tool that builds
>> sdists or wheels. That is, when metadata 2.0 support is added to
>> distutils/setuptools/... it should document how the metadata is configured.
>
>
> So a package author creates a package that only works with Python 3, builds
> a sdist using a tool-specific option that states this, and that data isn't
> recorded in the sdist so that whoever uses the sdist to build a wheel has to
> find that out elsewhere and re-specify it to build a wheel? That sounds
> wrong, unless I'm misunderstanding you...

This is a build problem. The metadata 2.0 spec *deliberately* avoids
trying to solve build problems, it merely leaves the door open to
attempting to solve them in the future. It *may* make sense for a
build tool to check the "supports_environment" flags for implied
options when building a wheel, but that's up to the build tool
developer.

Designing a metabuild system that is actually better than the setup.py
based command line API is an incredibly hard problem, and I'm not yet
convinced it's a problem we really need to solve. Killing "setup.py
install"? Sure, that definitely needs to happen and decoupling the
intergrator's choice of install tool from the developer's choice of
build tool is the main aim of metadata 2.0. Killing "setup.py
dist_info/sdist/bdist_wheel/test", though? I'm *not* convinced that
needs to happen, since there's no way to decouple of project's build
system from itself and projects like d2to1 show that creating a
setup.py based shim for an alternate build system doesn't need to be
*that* painful, particularly once there are well documented standard
archive formats to target. Even if a setup.py replacement on the build
side does happen eventually, it's a long way down the priority list.

In the meantime, once sdist 2.0 is officially defined in a PEP, build
tools will be able to define their own metadata extensions to record
whatever they want in the sdist files. They'll also be free to add
arbitrary files to the dist-info directory and have them propagate
through the wheel files and all the way to the installation database.

Cheers,
Nick.

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