[Distutils] setup_requires for dev environments

[Daniel Holth]

We could support this syntax right now. It's so simple. Don't deride
it as a pseudo standard, turn it into an actual standard and praise it
as something practical that will not take years to implement. Then
after those years have passed and the new PEP actually works and has a
distutils replacement to drive it, deprecate the old standard.

If you can come up with something better that can ship before 2016, by
all means.

[metadata]
setup-requires = cffi
    pip
    pycparser >= 2.10



https://bitbucket.org/dholth/setup-requires

On Mon, Mar 16, 2015 at 11:06 AM, Donald Stufft <donald at stufft.io> wrote:
>
>> 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
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>