[Distutils] setup_requires for dev environments

[Donald Stufft]

> On Mar 15, 2015, at 9:05 PM, Robert Collins <robertc at robertcollins.net> wrote:
> 
> PEP 426 addresses build requirements for distributions of Python code,
> but doesn't directly help with development environments.
> 
> It seems to me that if we help development environments, that would be
> nice - and any explicit metadata there can obviously be reflected into
> PEP-426 data in future.
> 
> For context, the main use I have for setup_requires these days is
> projects with a version contained within the project, and for the use
> of pbr in openstack (and some other git hosted) projects.
> 
> Consider e.g. unittest2, which has its version information in one
> place inside the package; but setup imports unittest2 to get at that,
> so all the dependencies become setup_requires entries :(. I may change
> that to exec which Donald suggested on IRC [I'd been pondering
> something similar for a bit - but was thinking of putting e.g.a  json
> file in the package and then reading that for version data].
> 
> testtools has a similar bunch of logic in setup.py.
> 
> The openstack projects have a nice solution I think, which is that
> they write the egg metadata file and then read that back - both at
> runtime via pbr helpers and at build time when pbr takes over the
> build.
> 
> The problem with that, of course, is that pbr then becomes a
> setup_requires itself.
> 
> So, I'm wondering if we can do something fairly modest to make
> setup_requires usage nicer for devs, who won't benefit from PEP-426
> work, but share all the same issues. E.g. pip install git://... / pip
> install filepath / pip install -e filepath should be able to figure
> out the setup_requires and have things Just Work.
> 
> Something like:
> - teach pip to read setup_requires from setup.cfg
> 
> setuptools doesn't need to change - it will still try to check its own
> setup_requires, and if an older pip had been used, that will trigger
> easy_install as it does currently. There's a small amount of duplicate
> work in the double checking, but thats tolerable IMO.
> 
> We could go further and also teach setuptools how to do that, e.g. you'd put
> setup_requires='setuptools>someX' in setup.py
> and your real setup_requirements in setup.cfg.
> 
> That would be better as it would avoid double-handling, but we'd need
> some complex mojo to make things work when setuptools decides to
> self-upgrade :( - so I'm inclined to stay with the bare bones solution
> for now.
> 
> Thoughts?

I've been thinking about this proposal this morning, and my primary question
is what exactly is the pain that is being caused right now, and how does this
proposal help it? Is the pain that setuptools is doing the installation instead
of pip? Is that pain that the dependencies are being installed into a .eggs
directory instead of globally? Is it something else?

I'm hesitant to want to add another psuedo standard ontop of the pile of
implementation defined psuedo standards we already have, especially without
fully understanding what the underlying pain point actually is and how the
proposal addresses it.

---
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/20150316/52b051b6/attachment.sig>