[Distutils] distlib updated to include "entry point" functionality

PJ Eby pje at telecommunity.com
Wed Oct 10 00:56:02 CEST 2012

On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Clearly, distlib can't do things exactly
> the way they're done in pkg_resources and setuptools, since those are not
> considered suitable to go into the stdlib,

The two aren't 100% connected, even assuming the antecedent were true.
 Originally, Guido Pronounced that they *were* to be added to the
stdlib (for Python 2.5), and I withdrew them due largely to an
objection about the lack of third-party expertise in the underlying
formats -- an expertise that is now considerably more widespread,
especially thanks to you and Daniel.  ;-)

More to the point, though, if it's not possible for someone to create
a wrapper to reimplement these portions of the pkg_resources API, then
it's going to be harder to get people to port their code.

The challenge isn't necessarily that there are dozens of platforms
that rely on this feature explicitly; the challenge is that code which
uses pkg_resources APIs for these things is *intentionally ignorant*
of whether the feature is being used.  The entire point of the API is
to free the caller from worrying about the callee's needs, and the
callee's dependencies can be transparently met by distributions that
are not directly on sys.path, at least in the .egg or .wheel model of
things.  (If .wheel files are importable, anyway.)

> ISTM that the "exports" feature in distlib allows applications to cooperate in
> the same way as pkg_resources' entry points do, except for the fact that
> sys.path is not manipulated at all, meaning that all such cooperating
> applications are assumed to be installed on the path.

Do you mean that it is not possible to identify the entry points of an
arbitrary distribution?  What about obtaining information about the
extras required by an entry point?  (i.e., is it possible for someone
to make a common wrapper that re-adds sys.path management?)

> Actual importing is
> delayed until needed; scanning of distribution metadata for exports also
> happens on demand. Do you feel that this is insufficient to meet the
> performance concerns you mentioned?

Now that 3.3 includes a faster import mechanism, probably so.  Under
older Pythons, adding a large number of directories to sys.path could
badly affect startup performance, if plugins were installed as
directories instead of as zipfiles.

(As a general note, in case you aren't aware: the entire .egg format
was invented originally as a distribution+use format for application
plugins; Bob Ippolito suggested that in the general case, any Python
library could also be considered a "plugin" to Python itself, and then
things kind of took off from there...)

More information about the Distutils-SIG mailing list