<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/08/2010 13:31, <a class="moz-txt-link-abbreviated" href="mailto:exarkun@twistedmatrix.com">exarkun@twistedmatrix.com</a> wrote:
<blockquote
cite="mid:20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain"
type="cite">On 12:21 pm, <a class="moz-txt-link-abbreviated" href="mailto:mal@egenix.com">mal@egenix.com</a> wrote:
<br>
<blockquote type="cite">Tarek Ziad� wrote:
<br>
<blockquote type="cite">On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby
<a class="moz-txt-link-rfc2396E" href="mailto:pje@telecommunity.com"><pje@telecommunity.com></a> wrote:
<br>
..
<br>
<blockquote type="cite"><br>
So without specific examples of why this is a problem, it's hard to see
why
<br>
a special Python-specific set of configuration files is needed to
resolve
<br>
it, vs. say, encouraging application authors to use the available
<br>
alternatives for doing plugin directories, config files, etc.
<br>
</blockquote>
<br>
I don't have a specific example in mind, and I must admit that if an
<br>
application does the right thing
<br>
(provide the right configuration file), this activate feature is not
<br>
useful at all. So it seems to be a bad idea.
<br>
<br>
I propose that we drop the PLUGINS file idea and we add a new metadata
<br>
field called Provides-Plugin
<br>
in PEP 345, which will contain the info I've described minus the state
<br>
field. This will allow us to expose
<br>
plugins at PyPI.
<br>
<br>
IOW, have entry points like setuptools provides, but in a metadata
<br>
field instead of a entry_points.txt file.
<br>
</blockquote>
<br>
Do we really need to make Python packaging even more complicated by
<br>
adding support for application-specific plugin mechanisms ?
<br>
<br>
Packages can already work as application plugins by simply defining
<br>
a plugins namespace package and then placing the plugin packages
<br>
into that namespace.
<br>
<br>
See Zope for an example of how well this simply mechanism works out in
<br>
practice: it simply scans the "Products" namespace for sub-packages and
<br>
then loads each sub-package it finds to have it register itself with
Zope.
<br>
</blockquote>
<br>
This is also roughly how Twisted's plugin system works. One drawback,
though, is that it means potentially executing a large amount of Python
in order to load plugins. This can build up to a significant
performance issue as more and more plugins are installed.
<br>
<br>
</blockquote>
<br>
unittest will solve this problem by having plugins explicitly enabled
in its own configuration system, and possibly managed through a
separate tool like a plugins subcommand. The full package list will
*only* need to be scanned when managing plugins, not during normal
execution. <br>
<br>
Having this distutils2 supported "plugin declaration and discovery"
will be extremely useful for the unittest plugin system. Given that
plugins may need configuring after installation, and tools that handle
both activation and configuration can be provided, it doesn't seem a
heavy cost.<br>
<br>
The downside to this is that installing and activating plugins are two
separate steps. Given that each project can have a different set of
plugins enabled I don't see a way round it. <br>
<br>
Michael<br>
<br>
<blockquote
cite="mid:20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain"
type="cite">Jean-Paul
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Python-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk">http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.ironpythoninaction.com/">http://www.ironpythoninaction.com/</a>
<a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/blog">http://www.voidspace.org.uk/blog</a>
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.
</pre>
</body>
</html>