I'm currently in the process of adding the ability for users to extend the functionality of my desktop application (C++) using plugins scripted in python.
The naive method is easy enough. Embed the python static library and follow any number of the dozens of tutorials scattered around the web describing how to initialize and call python files, and you're pretty much done.
However...
What I'm looking for is more like what Blender does. Blender is completely customizable through python scripts, and it requires an external python executable. (Ie. python isn't actually embedded in the blender executable at all.) So, naturally, you can include any modules you already have in your site-packages directory when you are writing blender scripts. Not that that's advised, since that would limit the portability of your script.
So, what I want to know is if there is already a way to have your cake and eat it too. I want a plugin system that uses:
An embedded python interpreter.
The downside of Blender's approach is that it forces you to have a specific, possibly outdated version of python installed globally on your system. Having an embedded interpreter allows me to control what version of python is being used.
Firewall plugins.
Some equivalent of a
virtualenv
for each plugin; allowing them to install all the modules they need or want, but keeping them seperated from possible conflicts in other plugins. Maybezc.buildout
is a better candidate here, but, again, I'm very open to suggestion. I'm a bit at a loss as to the best way to accomplish this.As painless as possible...
For the user. I'm willing to go the extra mile, just so long as most of the above is as transparent to the plugin writer as possible.
If any of you folks out there have any experience with this sort of thing, your help would be much appreciated. :)
Edit:
Basically, the short version of what I want is the simplicity of virtualenv
, but without the bundled python interpreter, and a way to activate a specific "virtual environment" programmatically, like zc.buildout
does with sys.path manipulation (the sys.path[0:0] = [...]
trick).
Both virtualenv
and zc.buildout
contain portions of what I want, but neither produce relocatable builds that I, or a plugin developer can simply zip up and send to another computer.
Simply manipulating .pth files, or manipulating sys.path
directly in a script, executed from my application gets me half-way there. But it is not enough when compiled modules are necessary, such as the PIL.