On Tue, May 29, 2012 at 10:20 AM, Erik Bray <erik.m.b...@gmail.com> wrote:
> This particular solution works for me. But the point is that it can > be done pretty easily. However, the lack of a setup_requires-like > feature still makes things pretty impossible short of shipping a copy > of all the required setup hooks with the projects that use them. > Certainly doable, but far from ideal. > Right, and I don't think distutils2 can really add setup_requires without blessing a package manager. That means the alternative is shipping an altered setup.cfg with sdist builds, or using tools that generate setup.cfg in the first place, such that setup.cfg isn't the project's canonical form. Probably the simplest way to do it would be to just ship setup.cfg in the sdist -- as modified by the setup hooks, since this keeps the developer from having to use a different tool to generate the setup.cfg; it can all be done by setup hooks. In that case, the setup hooks themselves would need to be idempotent, so they don't mess things up if they run a second time in an sdist-ed version of the project. Another alternative would be to use a package manager bootstrap script in the project directory (ala ez_setup.py), which could then read and process a setup_requires from setup.cfg. But that's a much heavier-weight process; it would be much preferable if people could make all their setup_requires stuff run off an original copy only, and not be needed in an sdist copy. So for example, if you need Pyrex for generating C code, it should run pre-sdist, not post-sdist. (OTOH, it's possible that there are some distributions you need for building the package, for platform-specific build steps.)
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
