Pyitect - Plugin architectural system for Python 3.0+ (feedback?)

[Ian Kelly]

On Mon, Jun 8, 2015 at 10:42 PM, Ben Powers <ryexander at gmail.com> wrote:
> As importlib has been added in python 3 and up I decided to use it's
> abilities to create a plugin system for truly modular development in python.
>
> Pyitect has the ability to drop in components and resolve dependencies. Even
> load different versions of a dependency if two different libraries require
> two different versions.
>
> Pyitect gives each "plugin" it won private namespace to import the
> components it needs. and nothing else.
>
> Pyitect  organizes it self around the concept of a System. Each system can
> scan and load it's own set of plugins, in each system plugins can be enabled
> individually.
>
> Pyitect even comes with a very simple event system that it uses internal to
> fire event when plugins are found/loaded/ect for the developer to use.
>
> I've written up What I think is a quite comprehensive readme to go with it.
>
> Available on PyPi https://pypi.python.org/pypi?:action=display&name=pyitect
> and Github https://github.com/Ryex/pyitect
>
> I'm looking for feedback on what flaws the system may have and where I can
> improve. I'm always open to pull requests
>
> Looking forward to what the comunity thinks of this little project of mine.
> Thanks for your input and criticism.

You need to run your readme through a spell-check, as it's riddled
with typographical errors and quite hard to read. A grammar check and
a proofreader would also be useful.

> "on_enable": "dostuff.py", // optional, runs this file when the plugin is enabled

A path to a function would feel more Pythonic.

> mode -> (OPTIONAL) defaults to import on python 3.4 and up ecec otherwise: sets the import mode

Do the plugins need to be on the sys.path in order to be imported?

> provides -> a mapping of provided component names to prefix mappings

What are the "prefix mappings" and what are they used for?

> #file.py
> from PyitectConsumes import foo
>
> class Bar(object):
>     def __init__():
>         foo("it's a good day to be a plugin")

I don't understand this example. Is "PyitectConsumes" the name of a
component or part of Pyitect? Or is "foo" the name of the component?

> plugins = [system.plugins[n][v] for n in system.plugins for v in system.plugins[n]]

What are n and v?

> Plugins are loaded on demand when a component is loaded via
>
> System.load("<component name>")

What's the difference between this and the "PyitectConsumes" import?

> ### both in both cases relative imports DO NOT WORK. the plugin folder is temporarily added to the search path so absolute imports work but relatives will not.
>
> UNLESS the name of the file is __init__.py . In this special case the plugin folder is reconsidered as a python package and relative imports work as normal.

Isn't this just how relative imports normally work? Of course you
can't use a relative import outside of a package.

> Loaded pluginss do NOT store their module object in sys.modules

What about imports of plugin-local modules that are performed inside
the plugins? Do those also get cleaned up from sys.modules?

If I have version 1 of a plugin that imports a module from its
package, and version 2 of the same plugin that imports a module from
its package, are those imports going to conflict with one another?

> System.useing
> System.enabeled_plugins

Are these misspellings actually part of the API?

Also, earlier you appeared to instantiate the System class, but now
you appear to be just accessing attributes from the class directly.
What's the distinction between the class-level state and the
instance-level state?

> Providing multiple versions of a component from the same plugin

Is there a reason to do this as opposed to simply providing multiple components?