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

[Ian Kelly]

On Mon, Jun 22, 2015 at 2:32 AM, Ben Powers <ryexander at gmail.com> wrote:
> on Tue, Jun 16,  2015 at 17:49 Ian Kelly <ian.g.kelly at gmail.com> wrote
>
>>On Mon, Jun 8, 2015 at 10:42 PM, Ben Powers <ryexander at gmail.com> wrote:
>>> #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?>
>
>
> `PyitectComsumes` is a special module injected into sys.modules when the
> plugin module is imported and removed after the import is complete. it's
> name-space contains all the components declared as required in the plugin's
> .json

So this import can only be performed when the module is loaded, not
later when a component's functionality is being invoked?

>>> 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?>
>
>
> The PyitectConsumes import is for use inside plugins where dependencies are
> declared prior to import.
>
> System.load is for use in the application to load components. Plugins are
> not intended to know about the System they are being used in.
>
>
>>> 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?>
>
>
> Actually no... thats an oversight on my part. really I should temporally
> clone sys.modules inject the PyitectConsumes special module and then set it
> back to the original sys.modules dict after the import has been performed,
> that would secure the process more and prevent cluttering of sys.modules.

It seems to me that this could create new problems. For example,
suppose a plugin being loaded imports urllib, and then later the
application tries to import urllib. It's not in sys.modules, so the
import framework loads it again, and now there are two copies of
urllib floating around in the interpreter. I think you actually need
to diff sys.modules and then remove anything that's added but only if
its path falls within the path of the plugin directory.

The more that I think about this, I don't think that overloading the
import machinery like this is the right way for plugins to gain access
to components. If instead you just pass the module a context object
with a get_component method, then you won't have to muck around with
sys.modules as much, and the context object can remain available to
the plugin for later use.