-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to load a package as a plugin, and reference submodules? #4
Comments
A plugin is specifically a class, but the loader accepts modules and will look in the module for plugin classes. PluginLib doesn't care what you do within the classes or modules as long as you meet the spec defined in the parent class. Yes, you can import In your example, you just need to make sure you import the module containing the parent before calling Using the example from the docs, but spreading it out across
Define the parent in sample module
mypackage root
mypackage.module1
mypackage.module2
Loading and calling plugins in test module
Does that help? Let me know if there is something I didn't cover or you run into an issue. |
Thanks, that's really clear. What I failed to mention is that When the various submodules in
The import statement in the submodule doesn't seem to know about its new namespace, even when I use relative references. |
It sounds like
That's for Linux. On Windows it's a little different, but you can Google that if you need to. Basically you need to tell Python where to find packages. If they are installed they will be in the default path, and it will include the directory your initial code is in, but anything else it needs to be told about it. For the example above, if you rearrange the files like this:
And from the
But setting
It's not a PluginLib-specific error, PluginLib is reporting it because it was encountered while importing mypackage to load plugins. |
However, I realise that perhaps I've misunderstood how In which case perhaps my problem is that
Is it possible to avoid duplicate plugins? Should I not specify a |
mypackage does need to be in the path if you are going to use internal imports. An easy way to verify the paths is to run Yes, PluginLib is really just a wrapper around metaclasses and import magic. It relies on the same import machinery, but calls it in a way to make things flexible. The idea of You're getting duplicate warnings because it's finding the same class twice. The plugins get registered when they are loaded so if you're loading them manually and then loading them through PluginLoader, you'll get duplicates. It won't break anything and you can disable the warning with the warnings package, but it's probably better to resolve the issue. The prefix package is really just there so bare modules can be loaded by path without risking conflict with something else. I don't think it factors in here. |
Is it possible that the duplication occurs during the plugin directory walk? I'm providing |
Actually, as I debug, the issue seems to be the recursive importing of
I think that executing this import statement is causing my mypackage to be imported the first time (before PluginLoader completes its work). Then, once PluginLoader does complete, mypackage is imported the second time (now with the my app.plugins prefix). Does that sound possible? |
I don't think that's it exactly, but while working on another issue, it seems PluginLoader is loading package modules multiple times on Python 3.5+ . I will push up a fix for that soon and maybe that will solve your issue. I'm very curious. Will reply here once I push that up. |
Just pushed up some changes. Please see if that help with the duplicate imports. Assuming it does, I have a little maintenance work to do on the repo and then I can push a new version to PyPI. |
Pushed 0.9.0 to PyPI, so should be easier to test. Let me know if it improves things. |
Thank-you! This is working much better now. It also turns out that plugin duplication now depends on whether the imports inside I tested it out with a minimal example closer to my actual app:
This works! (Prior to your pluginlib 0.9 update, the above failed with What's interesting, is that if I switch
So relative imports worked as I'd hoped. Whereas using absolute imports does seem to result in |
I think the difference is due to the way the modules are imported when given as a path. In this case, It would be good to let these kind of behaviors go without a warning in cases like this, but this is actually handled in the I need to think on it a bit. You may want to consider using modules instead of paths. It uses a more direct import logic, so these types of issues shouldn't come up. That said, it really comes down to what kind of contract you want to have with your users. Using modules assumes your plugins are installed Python modules rather than a directory of Python modules. |
That all makes sense. Thanks for all your help and insight - really useful and much appreciated. |
@avylove, I love this plugin library. But I'm stuck on packages. Is it possible to point me to an example where a package is loaded as a plugin? For example, if I have the following:
How can I import submodule1.py from within init.py, or import submodule2 from within submodule.1py?
Thanks so much.
The text was updated successfully, but these errors were encountered: