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='setuptoolssomeX' 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?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
