<div dir="ltr">Wheel puts everything important in METADATA, except entry_points.txt. The requirements expressed there under 'Requires-Dist' are reliable, and the full METADATA format is documented in the pre-JSON revision of PEP 426. At runtime, once pkg_resources parses it, *.egg-info and *.dist-info look identical, because it's just a different way to represent the same data. Wheel's version of METADATA exists as the simplest way to add the critical 'extras' feature to distutils2-era *.dist-info/METADATA, necessary to losslessly represent setuptools packages in a more PEP-standard way. I could have completely redesigned the METADATA format instead of extending it, but then I would have run out of time and wheel would not exist.<div><div><br></div><div>This function converts egg-info metadata to METADATA <a href="https://bitbucket.org/pypa/wheel/src/54ddbcc9cec25e1f4d111a142b8bfaa163130a61/wheel/metadata.py?at=default&fileviewer=file-view-default#metadata.py-240">https://bitbucket.org/pypa/wheel/src/54ddbcc9cec25e1f4d111a142b8bfaa163130a61/wheel/metadata.py?at=default&fileviewer=file-view-default#metadata.py-240</a><br></div><div><br></div><div>This one converts to the JSON format. It looks like it might work with PKG-INFO or METADATA. <a href="https://bitbucket.org/pypa/wheel/src/54ddbcc9cec25e1f4d111a142b8bfaa163130a61/wheel/metadata.py?at=default&fileviewer=file-view-default#metadata.py-98">https://bitbucket.org/pypa/wheel/src/54ddbcc9cec25e1f4d111a142b8bfaa163130a61/wheel/metadata.py?at=default&fileviewer=file-view-default#metadata.py-98</a></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 15, 2017 at 8:27 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 February 2017 at 12:58, Nathaniel Smith <<a href="mailto:njs@pobox.com" class="gmail_msg" target="_blank">njs@pobox.com</a>> wrote:<br class="gmail_msg">
> On Wed, Feb 15, 2017 at 3:33 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>> wrote:<br class="gmail_msg">
>> - "requires": list where entries are either a string containing a PEP<br class="gmail_msg">
>> 508 dependency specifier or else a hash map contain a "requires" key<br class="gmail_msg">
>> plus "extra" or "environment" fields as qualifiers<br class="gmail_msg">
>> - "integrates": replacement for "meta_requires" that only allows<br class="gmail_msg">
>> pinned dependencies (i.e. hash maps with "name" & "version" fields, or<br class="gmail_msg">
>> direct URL references, rather than a general PEP 508 specifier as a<br class="gmail_msg">
>> string)<br class="gmail_msg">
><br class="gmail_msg">
> What's accomplished by separating these? I really think we should<br class="gmail_msg">
> strive to have fewer more orthogonal concepts whenever possible...<br class="gmail_msg">
<br class="gmail_msg">
It's mainly a matter of incorporating<br class="gmail_msg">
<a href="https://caremad.io/posts/2013/07/setup-vs-requirement/" rel="noreferrer" class="gmail_msg" target="_blank">https://caremad.io/posts/2013/07/setup-vs-requirement/</a> into the core<br class="gmail_msg">
data model, as this distinction between abstract development<br class="gmail_msg">
dependencies and concrete deployment dependencies is incredibly<br class="gmail_msg">
important for any scenario that involves<br class="gmail_msg">
publisher-redistributor-consumer chains, but is entirely non-obvious<br class="gmail_msg">
to folks that are only familiar with the publisher-consumer case that<br class="gmail_msg">
comes up during development-for-personal-and-open-source-use.<br class="gmail_msg">
<br class="gmail_msg">
One particular area where this is problematic is in the widespread<br class="gmail_msg">
advice "always pin your dependencies" which is usually presented<br class="gmail_msg">
without the all important "for application or service deployment"<br class="gmail_msg">
qualifier. As a first approximation:<br class="gmail_msg">
pinning-for-app-or-service-deployment == good,<br class="gmail_msg">
pinning-for-local-testing == good,<br class="gmail_msg">
pinning-for-library-or-framework-publication-to-PyPI == bad.<br class="gmail_msg">
<br class="gmail_msg">
pipenv borrows the Ruby solution to modeling this by having Pipfile<br class="gmail_msg">
for abstract dependency declarations and Pipfile.lock for concrete<br class="gmail_msg">
integration testing ones, so the idea here is to propagate that model<br class="gmail_msg">
to pydist.json by separating the "requires" field with abstract<br class="gmail_msg">
development dependencies from the "integrates" field with concrete<br class="gmail_msg">
deployment dependencies.<br class="gmail_msg">
<br class="gmail_msg">
In the vast majority of publication-to-PyPi cases people won't need<br class="gmail_msg">
the "integrates" field, since what they're publishing on PyPI will<br class="gmail_msg">
just be their abstract dependencies, and any warning against using<br class="gmail_msg">
"==" will recommend using "~=" or ">=" instead. But there *are*<br class="gmail_msg">
legitimate uses of pinning-for-publication (like the PyObjC<br class="gmail_msg">
metapackage bundling all its subcomponents, or when building for<br class="gmail_msg">
private deployment infastructure), so there needs to be a way to<br class="gmail_msg">
represent "Yes, I'm pinning this dependency for publication, and I'm<br class="gmail_msg">
aware of the significance of doing so"<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Nick.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" class="gmail_msg" target="_blank">Distutils-SIG@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class="gmail_msg">
</blockquote></div>