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

[Vinay Sajip]

PJ Eby <pje <at> telecommunity.com> writes:

> 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.

I will give some thought to migration concerns. I'm not sure exactly what the
best approach is, or if identical semantics are achievable in all areas.
 
> 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.)

I don't believe that wheels are meant to be directly importable, but I could
be wrong about that. I am not sure why callee dependencies need to be
transparently met by distributions not on sys.path; Broadly speaking, and
leaving eggs out of the picture, I would expect a distribution to declare its
dependencies, and for these to be installed in the appropriate site-packages
by the installer.

> Do you mean that it is not possible to identify the entry points of an
> arbitrary distribution?  What about obtaining information about the

At the moment, not for a completely arbitrary distribution, as we don't
have the metadata in non-installed distributions. Of course, an arbitrary
distribution could be unpacked to a temporary location and have the equivalent
of egg-info run to get the information; but for this to work ideally, such
information would need to be present in the archive metadata and also need to
be in the index. There are a number of ways this could happen - it's not
clear to me what the best way is, but I probably haven't thought about it
enough.

> extras required by an entry point?  (i.e., is it possible for someone
> to make a common wrapper that re-adds sys.path management?)

I think it's too early to say.

> > 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.

I assume from the context above that that you actually mean "no" as the
answer to the question "is it insufficient?", whereas I would take "probably
so" to mean "yes, it's insufficient".

Regards,

Vinay Sajip