[Distutils] Meeting info re: sdists

Paul Moore p.f.moore at gmail.com
Wed Oct 14 10:33:17 CEST 2015


On 14 October 2015 at 01:46, Robert Collins <robertc at robertcollins.net> wrote:
> On 14 October 2015 at 13:25, Marcus Smith <qwcode at 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


More information about the Distutils-SIG mailing list