[Distutils] setup_requires for dev environments

[Nick Coghlan]

On 17 March 2015 at 21:05, Donald Stufft <donald at stufft.io> wrote:
>
>> On Mar 17, 2015, at 5:52 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> While I understand that there are real reasons why PEP 426 needs more
>> work before being finalised, is there no way that you (Nick and Donald
>> mainly, but honestly anyone with a picture of what a world where PEP
>> 426 is implemented would look like) can list some well-defined
>> implementation tasks that people can *get on with*? The current
>> frustration seems to me to be less about PEP 426 blocking progress, as
>> about nobody knowing how they can actually help (as opposed to things
>> like the current debate, which seems to be rooted in the idea that
>> while PEP 426 should "solve" Robert's issue, nobody knows how that
>> solution will look, and what can be done to get there).
>>
>> Paul
>
> I would just implement it inside of Wheel. You’d technically be working
> on two PEPs at once, but I think the bare bones Wheel PEP is pretty
> simple. “All the same things as the last PEP, except with pydist.json”.
> More things could be added to the Wheel PEP of course, but that’s not
> related to PEP 426. Even if we don’t merge the Wheel parts (though we’d
> be able to merge the packaging parts for an in memory representation)
> immediately, it’d still give some idea about how well it’ll work. Using
> Wheel is a good target because that already uses a static file so it’s
> less of a change to get PEP 426 integrated there.

+1 from me. As noted in my other message, I believe the machinery to
generate it is actually already there, it's just generating it using
the old format from before I moved the optional parts into extensions
instead.

It's actually possible we could adopt a multi-phase approach to
rolling out PEP 426, such as:

Phase 0 (today): wheel generates various iterations of draft
pydist.json files in wheel 1.0 format files
Phase 1: PEP 426 is declared provisional (Oops, I still need to
propose that update to PEP 1...)
Phase 2: PyPI extracts and publishes the still-provisional PEP 426
metadata from uploaded wheel files
Phase 3: We define wheel 1.1 to include pydist.json

At this point, we'll have mostly exercised the backwards compatibility
in pydist.json, rather than the new stuff. I don't have a clear view
as to how the adoption of the *new* capabilities will work, as we get
the old chicken-and-egg problem of needing to update the build side
and the install side at the same time to really gain from them. One
possible way to go would be to have the initial pydist.json consumers
be redistribution tools like pyp2rpm, while pip continues to rely
solely on the old metadata files.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia