<div dir="ltr"><p dir="ltr">On Oct 1, 2015 10:45 PM, "Marcus Smith" <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
><br>
> Can you clarify the relationship to PEP426 metadata?<br>
> There's no standard for metadata in here other than what's required to run a build hook.<br>
</p><p dir="ltr">Right -- the idea is that discretely installable binary packages (i.e. wheels) are a different sort of thing than a source tree / source distribution, and need different metadata. PEP 426 is then taken as a draft of the next metadata spec *for wheels*, and this is a draft "simplest thing that could possibly work" metadata spec for source trees / source distributions. The "synopsis and rationale" section provides more motivation for this approach.<br></p><p dir="ltr">> Does that imply you would have each build tool enforce their own convention for where metadata is found?
</p><p>I think you mean: "does that imply that each build tool would have its own way of determining what metadata to attach to the wheels it generates?", and the answer to that is yes -- already right now distutils does it via kwargs passed to the setup() function, flit does it via entries in its flit.ini file (though for simplicity it might later move this to an extension section in _pypackage.cfg -- and note that this purely declarative style is only possible  because flit is designed to make simple things easy and complicated things someone else's problem), and in general it might require arbitrary code to be executed.</p><p>I expect that some conventions will probably get sorted out once we have experimental build systems competing with each other and figuring out what works and what doesn't, but distutils-sig has historically had poor luck with trying to design this kind of thing a priori.<br></p><p>-n<br>
</p>
</div>