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

[PJ Eby]

On Mon, Oct 8, 2012 at 5:14 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> What do *you* mean by entry point? My understanding is that it represents the
> start of some executable code. Wikipedia:
>
> "In computer programming, an entry point is a memory address, corresponding to a
> point in the code of a computer program which is intended as the destination of a
> long jump, be it internal or external."
>
> So, in the Python sphere, I would interpret an entry point to be a callable.
> While that might be the most common usage of the feature, it's not the only one.
> For example, you could use name = value entries where value is not a callable,
> but for example a name of a resource to use for something, or a configuration
> option, or the name of a package or a module (which is not an entry point by my
> understanding of entry points being callables).

In pkg_resources, entry points are references to any importable
object.  They don't have to be callables.

Note, however, that if you load an entry point which is a module, then
of course the module code will be executed as a side-effect, so
technically, a module still meets the "start of some executable code"
standard.  ;-)

In any case, the name was chosen for the primary use case of
designating executable entry points in Python code, often callables.
However, given the nature of Python, there was absolutely no reason to
restrict them to referring *only* to callables.  (In fact, the
feature's name and implementation was inspired by Eclipse's "extension
points" architecture, where the advertised objects usually implement
interfaces with more than one method.)

If the name *must* be changed, I'd suggest using "exports", for
symmetry with "imports".  Entry points are always the name of an
importable object, and they are basically being advertised so that
other code knows what is available to be imported, and the loading API
allows one to handle other details such as updating sys.path as
necessary, and doing the actual import.

I understand that right now you're not supporting those other features
in distlib, but I feel I should mention as a reminder that many of
these pkg_resources features were created to support application
platforms with plugins, such as Trac, Zope, Chandler, etc., and to
prevent the need for wheel-reinvention between different Python plugin
systems.  For this type of platform, it's often an important core
feature to be able to dynamically add plugins and their requirements
to sys.path on an as-needed basis when the entry points are actually
*used*, because early loading or additions to sys.path can
dramatically affect application startup times.

That's why I baked those features into entry points from the beginning
- I was battling what was at the time an excruciating slow startup for
the Chandler application platform, and I borrowed the architectural
pattern of delayed loading of plugins from Eclipse.  (I also remember
that Ian Bicking was talking about some problem, maybe on the Web-SIG,
and I remember that the problem he was talking about could be solved
by something like entry points, at which point I then had a solution
for both Ian's problem and Chandler's problem.)