[Distutils] command hooks...

PJ Eby pje at telecommunity.com
Wed May 30 01:41:30 CEST 2012

On Tue, May 29, 2012 at 5:17 PM, Carl Meyer <carl at oddbird.net> wrote:

> On 05/29/2012 02:01 PM, PJ Eby wrote:
> > On Tue, May 29, 2012 at 1:24 PM, Carl Meyer <carl at oddbird.net> wrote:
> >     On 05/29/2012 08:19 AM, PJ Eby wrote:
> >     > Right, and I don't think distutils2 can really add setup_requires
> >     > without blessing a package manager.
> >
> >     I'm confused by this statement. distutils2 _includes_ a package
> manager
> >     (pysetup); it has no need to bless an external one. What am I
> missing?
> >
> > I might be confused; I haven't been following the goings-on of late with
> > distutils2.  At one point, I thought the plan was not to bless or
> > include dependency-managing installers with the stdlib, or something
> > like that.  i.e., I thought the plan wasn't to support or bless
> > full-service tools like buildout, easy_install, or pip, or anything
> > comparable to them.
> Right, yeah, the plans in this area were fluid for awhile, but the
> eventual conclusion was that the stdlib should have a command-line
> utility capable of installing packages with dependencies. That exists in
> default branch now; it's called pysetup. It doesn't have nearly all the
> features of easy_install, buildout, or pip, but it can install packages
> from an index with deps.
In any case, it still doesn't change the part where it's a good idea to
ship a static setup.cfg, with hooks only needing to run on the
sdist-building machine, unless they are actually part of the build
process.  There are use cases for calculated data to be in the initial
setup.cfg, where the calculation machinery doesn't need to be on the target
(like generating the file list or version from revision control info).  So,
a setup_requires (or maybe better named "build_requires") would still be
helpful, but probably shouldn't be used for setup.cfg stability.

One use case I ran across rather late in the game with setuptools was the
part where sdist distributions need to be capable of rebuilding an sdist,
for at least the bdist_rpm case, if not others.  That had me tearing my
hair, since I was dependent on what I could do on top of existing
distutils.  But for distutils2, shipping an updated setup.cfg (possibly
*minus* certain setup_hooks) would solve the problem nicely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120529/604f64e0/attachment.html>

More information about the Distutils-SIG mailing list