<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Apr 25, 2013, at 10:47 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><p dir="ltr">I plan to reject PEP 390, since that feature won't be added to the stdlib.</p>
<p dir="ltr">The reason we will need at least a minimal replacement for it is so that there's a standard place to define and retrieve the archiver hook that creates the sdist (and hence pymeta.json) from a source tarball or VCS checkout (as well as determine the necessary dependencies for that step).</p></div></blockquote><div>A minimal file that only requires what's needed for bootstrapping the archiver is fine. </div><blockquote type="cite"><div>
<p dir="ltr">My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, though, is as a sanity check on the proposed PEP 426 metadata. If I can't come up with a clean multi-file input format, then I will be highly suspicious of the underlying data model.</p></div></blockquote><div>I don't see anything wrong with making this spec but I don't think it should be conflated with the PEP for a standard way to bootstrap the archiver. I also don't think it belongs as a PEP as its not a proposal to enhance python just a test of the new metadata and an example of what an archiver _could_ use as its format. </div><blockquote type="cite"><div>
<p dir="ltr">Cheers,<br>
Nick.</p>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a></span><br><span><a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a></span><br></div></blockquote></body></html>