On 22 June 2013 00:10, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 June 2013 14:30, Ronald Oussoren <ronaldoussoren@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@gmail.com | Brisbane, Australia