On 30/07/2010 15:37, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw<ba...@python.org> wrote:
..
* Registration - How do third party plugins declare themselves to exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is installation of the plugin enough to register it? How do end users
enable and disable plugins that me be registered on their system? How do
plugins describe themselves (provide short and log descriptions, declare
options, hook into command line interfaces, etc.)?
* Installation - How are plugins installed on the system? Do they have to
appear in a special directory on the file system? Do they need special
setup.py magic to write extra files? Do they need to live in a pre-defined
namespace?
FWIW We are thinking about adding in distutils2 a system quite similar
to the entry points
setuptools has, but with extra abilities for the end user :
- activate / deactivate plugins without having to remove the project
that added them
- configure globally if plugins are implicitely activated or not --
and maybe allow the distutils2 installer to ask the user
when a plugin is detected if he wants it activate or not
- provide a tool to browse them
This will be done through files added in the dist-info/ dirs, with the
new PEP 376 api we are
adding to pkgutil
The idea is that the end user should be able to have a full control on
what's activated in his system,
without relying on the developer choices
This system sounds great. unittest could certainly use it for
discovering plugins provided by other packages.
The question then is still how to decide which ones should be active for
any individual project (just because a plugin is available doesn't mean
you want it used for every project). A configuration system is still
good for this, but that kind of negates the advantage of discovery if
the user still has to configure the plugin *anyway*.
For framework authors not using the default test runner ("python -m
unittest" or "unit2") this would be very useful.
Michael
Cheers
Tarek
--
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
