| 1 |
I've had a go at creating a generic plugin framework for portage. The attached |
| 2 |
patch contains: |
| 3 |
|
| 4 |
* plugins/__init__.py that does plugin searching and loading. |
| 5 |
* plugins/cache/__init__.py which specifies what class cache plugins must |
| 6 |
derive from. |
| 7 |
* cache/{anydbm,flat_hash,flat_list,metadata,sqlite}.py copied to |
| 8 |
plugins/cache/ with imports adjusted and classes renamed to match their |
| 9 |
filenames. |
| 10 |
* portage.py edits to the config class to make use of the framework. |
| 11 |
|
| 12 |
Essentially, plugins.registry gives dict access to modules under plugins/. To |
| 13 |
give an example, the plugins.cache.anydbm.anydbm class can be accessed via |
| 14 |
plugins.repository["cache"]["anydbm"]. |
| 15 |
|
| 16 |
In loading, I'm iterating through sys.path and chopping that out from the |
| 17 |
detected module's path. I didn't need to do this when I was first testing the |
| 18 |
module loader, however. After integrating it with portage I was getting |
| 19 |
"module not found" errors. If anybody knows why that is, I'll get rid of that |
| 20 |
iteration. To be clear, the following doesn't work only when running from |
| 21 |
portage (regardless of the path used): |
| 22 |
|
| 23 |
python -c '__import__("/usr/lib/portage/pym/cache")' |
Archives