I'm developing a python framework that would have "addons" written as separate packages. I.e.:
import myframework
from myframework.addons import foo, bar
Now, what I'm trying to arrange is so that these addons can be distributed separately from core framework and injected into myframework.addons
namespace.
Currently my best solution to this is the following. An add-on would be deployed (most likely into {python_version}/site-packages/
like so:
fooext/
fooext/__init__.py
fooext/myframework/
fooext/myframework/__init__.py
fooext/myframework/addons/
fooext/myframework/addons/__init__.py
fooext/myframework/addons/foo.py
The fooext/myframework/addons/__init__.py
would have the pkgutil path extension code:
import pkgutil
__path__ = pkgutil.extend_path(__path__, __name__)
The problem is that for this to work, the PYTHONPATH needs to have fooext/
in it, however the only thing it would have is the parent install directory (most likely, the above-mentioned site-packages
).
The solution to this is to have extra code in myframework/addons/__init__.py
which would tranverse sys.path
and look for any modules with a myframework sub-package, in which case it adds it to sys.path
and everything works.
Another idea I had is to write the addon files directly to myframework/addons/
install location, but then it would make development and deployed namespace differ.
Is there a better way to accomplish this or perhaps a different approach to the above distribution problem altogether?
See namespace packages:
http://www.python.org/dev/peps/pep-0382/
or in setuptools:
http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages