[Python-Dev] PEP 376 proposed changes for basic plugins support (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Mon Aug 2 20:48:29 CEST 2010

On 02/08/2010 19:45, Holger Krekel wrote:

On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord<fuzzyman at voidspace.org.uk> wrote:

On 02/08/2010 19:05, Holger Krekel wrote:

On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking<ianb at colorstudy.com> wrote:

Just to add a general opinion in here: Having worked with Setuptools' entry points, and a little with some Zope pluginish systems (Products.*, which I don't think anyone liked much, and some ways ZCML is used is pluginish), I'm not very excited about these. The plugin system that causes the least confusion and yet seems to accomplish everything it needs is just listing objects in configuration -- nothing gets activated implicitly with installation, and names are Python package/object names without indirection.

This makes it a two-step process to use a plugin: install it and then configure it correctly to have it used. I'd much prefer a one-step process and rather provide a way to not-use a plugin even if installed. The difference is e.g. with py.test that i can point users to e.g. pip install pytest-figleaf py.test --figleaf How do you achieve this currently? it uses setuptools entrypoints, so with a setup.py param like

Right. I can't use that for unittest. With the new proposal we could automatically use all available plugins, but I think I prefer to only have plugins active that the user has chosen.

Michael

entrypoints = {'pytest11': ['pytestfigleaf = pytestfigleaf'],},

py.test's pluginmanager.py does: for ep in pkgresources.iterentrypoints('pytest11'): # ... ep.name == "pytestfigleaf"<- left side of above "=" plugin = ep.load() #<- right side of above "=" # ... best, holger

Michael

instead of also having to explain a configuration file, its location and exact content or some magic attribute variables on some classes. TBH, i'd like to have pip handle plugins, based on metadata (especially some data signaling something is a plugin of otherthing). This way i only once have to teach about "pip" and people leverage their knowledge for installing/managing plugins. best, holger

The only thing I'd want to add is the ability to also point to files, as a common use for plugins is adding ad hoc functionality to an application, and the overhead of package creation isn't always called for. hg for example seems both simple and general enough, and it doesn't use anything fancy. Purely for the purpose of discovery and documentation it might be helpful to have APIs, then some tool could show available plugins (especially if PyPI had a query interface for this), or at least installed plugins, with the necessary code to invoke them. Maybe it would make sense to generalize the discovery of plugin types, so that you can simply refer to an object and the application can determine what kind of plugin it is. But having described this, it actually doesn't seem like a useful thing to generalize. -- Ian Bicking | http://blog.ianbicking.org

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- 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.

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

More information about the Python-Dev mailing list