<p dir="ltr"><br>
On Oct 14, 2015 3:33 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 14 October 2015 at 01:46, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> > On 14 October 2015 at 13:25, Marcus Smith <<a href="mailto:qwcode@gmail.com">qwcode@gmail.com</a>> wrote:<br>
> >><br>
> >><br>
> >> thanks for the summary!<br>
><br>
> Agreed.<br>
><br>
> >><br>
> >>> * Things that have reason to change (deps) are more reasonable to be<br>
> >>> dynamic (even with PEP-426 markers there are exceptions)<br>
> >><br>
> >><br>
> >> as we know, for *many* cases, run-time deps aren't dynamic.<br>
> >> is there a consensus for those cases? exist in the sdist metadata? or no?<br>
> ><br>
> > The plan we hashed out (this would be the new PEP on static metadata in sdists)<br>
> > - pip etc to lint and error if they encounter a malformed dist-info in an sdist<br>
> > - then start putting dist-info, not egg-info into sdists<br>
> > - for any field if the field is entirely absent, we'll get it by<br>
> > running the dist-info build-tool command I described in the other<br>
> > mails</p>
<p dir="ltr">so, validate and transform to OrderedDicts which can then be json.dump'd to metadata.jsonld?</p>
<p dir="ltr">> ><br>
> > Concretely:<br>
> > {'build_requires': []} -> no build requirements<br>
> > {} -> get build requirements by running the build system<br>
><br>
> One use case that I don't think is covered here is publishing<br>
> dependency metadata via PyPI. I believe distlib needs this for some<br>
> functions (at the moment, I think it uses an externally hosted set of<br>
> package dependency data that's maintained by Vinay), and I know there<br>
> have been a number of utility scripts I've needed to write that I<br>
> simply haven't been able to because doing so would involve a<br>
> significant amount of extra work downloading and running package code.<br>
><br></p>
<p dir="ltr">> If there are dependencies that are only detectable at wheel build<br>
> time, then so be it (I'm still looking for an example, but it's clear<br>
> that the potential is there) but I'd like some way of getting at<br>
> whatever dependency information a wheel (source or binary) provides<br>
> via the PyPI JSON API - and I'd like an assurance that if dependency<br>
> information *can* be determined statically, it will be.</p>
<p dir="ltr">* the ship has already sailed on a static declarative dependency model (because 'if sys.platform:' in setup.py<br>
* I agree that we should preserve all (dynamically determine at setup.py runtime) requires edges as static JSON-LD</p>
<p dir="ltr">><br>
> Paul<br>
> _______________________________________________<br>
> Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>