1 |
I have recently been doing a re-write of eclean and one of the problems |
2 |
to address was the need to run "emaint fix packages" when doing any |
3 |
cleaning of the packages directory. Since eclean and emaint are coded |
4 |
in python, I looked into importing the emaint code and running it from |
5 |
within eclean. Currently emaint is an all inclusive script without any |
6 |
easily import-able modules. Asking Zac, he stated that it would be fine |
7 |
to change that to a cli script and library. |
8 |
|
9 |
So, going through the code, I found it pretty much was already |
10 |
modularized but just stuck together in the one file. In there was also |
11 |
a TODO message: |
12 |
|
13 |
|
14 |
# TODO: Create a system that allows external modules to be added without |
15 |
# the need for hard coding. |
16 |
modules = { |
17 |
"world" : WorldHandler, |
18 |
"binhost":BinhostHandler, |
19 |
"moveinst":MoveInstalled, |
20 |
"movebin":MoveBinary, |
21 |
"cleanresume":CleanResume |
22 |
} |
23 |
|
24 |
|
25 |
So having a bit of experience with porthole's plug-in system, I took it |
26 |
upon myself to create a small plug-in system. I also designed it to load |
27 |
as little code as possible. With this plug-in system emaint actually |
28 |
runs slightly faster than the original script. The only changes |
29 |
being done were to use the plug-in system and independent module files |
30 |
containing the original unmodified module class. I believe the |
31 |
speed increase is due to python not having to load as much script, as |
32 |
only the module's __init__.py for all modules is loaded initially and |
33 |
then the requested operation module file is loaded. |
34 |
|
35 |
I think you will find this plug-in system very straightforward, perhaps |
36 |
a little overkill for emaint. But it does offer a number of advantages |
37 |
including less code changes to add/remove modules, full module usability |
38 |
by other apps, etc.. Fully re-useable plug-in system for other apps |
39 |
(when complete). |
40 |
|
41 |
|
42 |
I have a bzr branch of portage's svn trunk with the modified emaint. It |
43 |
is fully functional for your testing and review of the code. I do have a |
44 |
little more work to do on it. So far I have not modified the code to |
45 |
make use of the 'functions' and 'func_desc' data provided by the modules |
46 |
__init__.py module_spec dictionary. It is currently relying on the |
47 |
original hard coded ['check', 'fix'] functions in the different module |
48 |
classes. It has also been suggested to make the modules dictionary a |
49 |
LazyLoad dictionary instead. |
50 |
|
51 |
|
52 |
I have a bzr branch available: |
53 |
|
54 |
bzr co http://dev.gentooexperimental.org/~dol-sen/bzr/portage-trunk/ |
55 |
|
56 |
If I did it correct, I also have migrated it to a git branch too: |
57 |
|
58 |
git remote add emaint http://dev.gentooexperimental.org/~dol-sen/git/portage.git/ |
59 |
git fetch emaint |
60 |
git branch emaint |
61 |
|
62 |
and test/review it. |
63 |
|
64 |
|
65 |
I have attached 2 module __init__.py's and the module.py file for |
66 |
your perusal without the need to checkout a copy of my repo. |
67 |
|
68 |
For those of you getting a bzr checkout or git remote to test. Try |
69 |
moving modules in and out of the modules dir and then run emaint -h. |
70 |
Also the vdbkeys module is old and no longer usable, so will not be |
71 |
included in the final version should it be approved and implemented. I |
72 |
include it here so you can see how easily modules can be added/removed. |
73 |
|
74 |
I have also coded up a dummy module demonstrating the ability to |
75 |
automatically change the class returned for a module name according to |
76 |
an environment variable setting. But there are a number of other ways |
77 |
that it could use too. |
78 |
-- |
79 |
Brian Dolbec <brian.dolbec@×××××.com> |