[Distutils] setup_requires for dev environments

[Donald Stufft]

> On Mar 17, 2015, at 5:52 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 16 March 2015 at 23:24, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> However, now that I know folks are keen to help with that side, I can
>> reprioritise getting the updates done so there's a better base to start
>> working from.
> 
> The thing I struggle with over PEP 426 is that as a data format
> definition, which explicitly describes itself as defining an in-memory
> representation, it's not clear to me what coding tasks are needed. (I
> don't have enough experience with complex build environments to help
> with the specification of the metadata, so my interest is in coding
> tasks I can help with).
> 
> Writing pydist.json files is explicitly deferred to the yet to be
> written Sdist 1.0, Wheel 1.1, and new distribution database PEPs.
> 
> The build system interface remains obscure (although there's note of a
> further PEP to define the command line interface) because we don't
> want to mandate the setup.py interface, but nobody has yet to come up
> with a better idea. And there's not even a mention of a PEP covering
> something like setup.cfg as a declarative means of providing metadata
> into the build system (unless that comes under the "command line API"
> description).
> 
> So we're left in a situation where there are people willing to help,
> at least with the coding tasks, but no obvious implementation tasks to
> work on. And yet people still see problems that we expect to be fixed
> by "Metadata 2.0". So it does feel somewhat like a block on progress.
> 
> 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.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150317/2f4653ca/attachment.sig>