On 30/07/2010 21:56, P.J. Eby wrote:
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configuring *which*
plugins you wish to have active. Entry points support access by name,
and it's up to the application using them to decide *which* ones to load.
The underlying idea is that entry points expose a hook; it's up to the
app to decide which ones it should actually import and use. An
application also can list the available plugins and ask the user, etc.
(For example, setuptools only loads "setup() argument" entry points
for specified arguments, and command entry points only for the
commands a user explicitly invokes.)
IOW, entry points provide access to plugins, not policy or
configuration for *which* plugins you wish to use. This was an
intentional decision since applications vary widely in what sort of
configuration mechanism they use. In the simplest cases (e.g.
single-app environments like Chandler), simply making the plugin
available on sys.path (e.g. via a special plugins directory) is
configuration enough. In more complex use cases, an app might have to
import plugins in order to get more information about them.
Right (and thanks), and in the unittest plugin system the user decides
which plugins should be active by listing them explicitly in the
configuration file.
Discovery could be useful for a tool that tells the user which plugins
are available and modify the config file *for them* to switch plugins on
and off. Useful metadata would then be which config options a plugin
supports (and their defaults) so they can be added to the config file
too when a plugin is activated.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
