Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <brian.dolbec@×××××.com>
To: gentoo-portage-dev <gentoo-portage-dev@l.g.o>
Subject: [gentoo-portage-dev] proposed emaint changes
Date: Sun, 28 Mar 2010 09:27:48
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.
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:
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 }
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 for all modules is loaded initially and
33 then the requested operation module file is loaded.
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).
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 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.
52 I have a bzr branch available:
54 bzr co
56 If I did it correct, I also have migrated it to a git branch too:
58 git remote add emaint
59 git fetch emaint
60 git branch emaint
62 and test/review it.
65 I have attached 2 module's and the file for
66 your perusal without the need to checkout a copy of my repo.
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.
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>


File name MIME type text/x-python text/x-python text/x-python
signature.asc application/pgp-signature