[Distutils] setup_requires for dev environments

[Donald Stufft]

> On Mar 17, 2015, at 7:43 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 17 March 2015 at 11:38, Donald Stufft <donald at stufft.io> wrote:
>>> OK, cool. So bdist_wheel to write a pydist.json into the wheel, and
>>> then I guess wheel install (and pip) will just pick it up and dump it
>>> in the dist-info folder because they do that anyway. Sounds easy
>>> enough.
>> 
>> I would also modify pip to start using it as part of the validation of
>> this PEP (inside of a PR). That should “close the gap” and say “hey look
>> we have a Proof of Concept here of this all working”.
> 
> I'm still not clear what you expect pip to *do* with the metadata.
> It's just data, there's no functionality specified in the PEP.

What pip does now with metadata, Look at it for dependency information when
installing the Wheel, show it when doing ``pip show``, handle the Provides
metadata making something “Provide” something else, show warnings for the
obsoleted-by metadata, handle extensions (including failing if there is a
critical extension we don’t understand).

I’m not actually sure what you mean by “there’s no functionality specified
in the PEP” because there is quite a bit of new functionality that’s implicitly
inside the PEP just from the new types of data it includes.

> 
>>> Which only leaves the question of how users specify the metadata. My
>>> feeling is that anything that isn't already covered by arguments to
>>> setup() should be specified declaratively. That may be in setup.cfg,
>>> but ini format may be a PITA for some of the more structured data. I
>>> can have a think about that…
>>> 
>> 
>> I would personally declare it inside of setup.py like everything else,
>> yea setup.py is gross and unfun in 2015, however I think having two
>> different locations for metadata inside of setuptools based on what era
>> of spec that metadata came from is going to be super confusing for end
>> users.
> 
> OK, that makes sense. But that involves setuptools hacking, which I'm
> not touching with a bargepole :-)

Ha, that makes sense :) For a proof of concept doing whatever makes sense
to you in that regards makes sense too FWIW.

> 
> Paul

---
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/9aca3e05/attachment.sig>