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
On Mar 15, 2015, at 9:05 PM, Robert Collins
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@python.org https://mail.python.org/mailman/listinfo/distutils-sig