[Python-Dev] PEP 376 proposed changes for basic plugins support

Holger Krekel holger.krekel at gmail.com
Mon Aug 2 20:45:48 CEST 2010


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

    entry_points = {'pytest11': ['pytest_figleaf = pytest_figleaf'],},

py.test's pluginmanager.py does:

        for ep in pkg_resources.iter_entry_points('pytest11'):
            # ... ep.name == "pytest_figleaf" <- 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.
>
>
>


More information about the Python-Dev mailing list