[Distutils] command hooks...

[PJ Eby]

On Fri, May 25, 2012 at 4:23 PM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Fri, May 25, 2012 at 2:24 PM, Daniel Holth <dholth at gmail.com> wrote:
> > This discussion is confusing because we are either talking about a
> > general plugin discovery mechanism for Python, or a plugin mechanism
> > that packaging itself uses.
> >
> > After the patch, entry_points.txt (which you are encouraged to write
> > yourself) is copied by means of a new {dist-info} category using the
> > resources = mechanism in packaging. This is a straightforward way to
> > copy anything into the .dist-info directory. Apart from copying the
> > file, 'packaging' has no role.
> >
> > setup.cfg:
> >
> > [files]
> > packages = mypackage
> > resources =
> >    entry_points.txt={dist-info}
> >
> > That's all there is to it.
>
> Neat! I didn't realize there was a {dist-info} resource category.
> That, plus the register_finder() approach mentioned in the other
> thread could be a way to go for interoperability with packages using
> setuptools.  It would still require a bit of hackery though...  I
> suspect there would be resistance to adding support for this directly
> in packaging.  But a setup_hook could set this up.
>

Ideally, one should just be able to add sections to setup.cfg itself to
describe the entry points.  Better yet: just include setup.cfg in the
dist-info directory, and then the replacement for entry points can look for
arbitrary sections in setup.cfg files.  (The downside: slower first-use
performance, since every setup.cfg would have to be read at least once, but
on the upside, all subsequent entry point lookups would be faster.)

Is setup.cfg already in dist-info?  I guess if it isn't, you could just add
it, using the same mechanism above.  Hm....  (goes to look at packaging
docs)...  Ouch.  I'm seeing a bigger problem, which is that without either
the ability to do "setup_requires" or to ship an sdist with a hook-altered
setup.cfg, it doesn't look like you can actually implement all of
setuptools' build functionality with just packaging.  (e.g. Setuptools can
ship an sdist whose contents and version were determined using revision
control info, but which does not then require the revision control tool
when installing from the sdist, as the sdist contains a pre-built manifest,
and a pre-built setup.cfg with hardcoded version numbers copied from the
original revision control info.)

I really hope I'm not going to have to write setuptools2 to work around
these limitations.  ;-)   (Preferably, if I do write a setuptools2, I hope
it can all be done using proper setup hooks on top of packaging/distutils2,
without monkeypatching anything.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120527/7ff8b152/attachment-0001.html>