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