On 17 March 2015 at 19:52, Paul Moore <p.f.mo...@gmail.com> wrote: > On 16 March 2015 at 23:24, Nick Coghlan <ncogh...@gmail.com> wrote: >> However, now that I know folks are keen to help with that side, I can >> reprioritise getting the updates done so there's a better base to start >> working from. > > The thing I struggle with over PEP 426 is that as a data format > definition, which explicitly describes itself as defining an in-memory > representation, it's not clear to me what coding tasks are needed. (I > don't have enough experience with complex build environments to help > with the specification of the metadata, so my interest is in coding > tasks I can help with).
That's a fair request. Something I perhaps haven't been clear about is that PEP 426 is *just* an interoperability spec - it defines the interfaces between tools so they can share a common data model. It deliberately *doesn't* fully define the user experience that build tools and download tools are going to wrap around it (it places *constraints* on that experience through some of its clauses, but still falls long way short of actually defining it). The idea here is to allow developers to choose the build system *they* like, and then have PyPI, pip, easy_install, et al, all be able to happily consume that metadata, regardless of the specific build system used. That's an easier bar to meet for wheel files than it is for sdist's, but the long term aim is to achieve it for both. > Writing pydist.json files is explicitly deferred to the yet to be > written Sdist 1.0, Wheel 1.1, and new distribution database PEPs. That's the timeline for the formal definition, in practice "drop pydist.json in the existing directory" as PEP 426 suggests is a fairly safe bet as to what those specs are going to say. The "don't rely on it unless the container version says it's OK to do so" caution in the PEP is primarily because wheels already ship with pydist.json metadata emitted based on an earlier draft version of the spec (from before I gutted it and moved the optional sections out to PEP 459 as standard extension modules, which is also the change that did the most damage when it came to invalidating the current jsonschema definition). On the generation side, there's thinking about how the d2to1 (i.e. setup.cfg) and setuptools (i.e. setup.py) APIs for entering the new metadata might look, taking into account that existing input files need to continue to work, and existing output files need to continue to be generated. Most of that can be worked through even while some specific field names are still being tinkered with. One option on that front may be to propose introducing a setup.yaml file as the preferred human-facing format that both d2to1 and setuptools understand, as I suspect some of the concepts in PEP 426 are going to be hellishly awkward to map to the ini-style syntax of setup.cfg (in particular, the nested format for defining conditional dependencies based on extras and environment markets). One particularly valuable capability is being able to take an existing project and generating pydist.json for it based on the existing metadata files without needing to change anything. https://www.python.org/dev/peps/pep-0426/#appendix-a-conversion-notes-for-legacy-metadata covers the current partial implementations of that feature which all need updating to account for subsequent changes to the spec. One of the overarching goals here is to be able to publish this info as static metadata on PyPI so folks can more easily do full dependency network analysis without having to download all of PyPI. Vinay built a system like that based on distlib (by first downloading all of PyPI), and one of the ideas behind PEP 426 is to let us publish that kind of info for easier analysis even before we upgrade the actual installers to make use of it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
