1 |
While making changes to catalyst for the tree move I noticed that there |
2 |
is in my view a serious design flaw in the way the python modules for it |
3 |
are laid out. |
4 |
|
5 |
The modules directory has no __init__.py so is not automatically |
6 |
recognized by python as a directory containing python code... So, there |
7 |
is code in the main catalyst script to insert that path to it's modules |
8 |
so that they are found. |
9 |
|
10 |
Inside that modules directory is the main catalyst python package |
11 |
directory. |
12 |
|
13 |
These two directories are reversed. The modules directory should be |
14 |
nested inside the catalyst directory and have an __init__.py file so |
15 |
that they are properly and automatically inside the catalyst namespace. |
16 |
|
17 |
The same is true of the arch directory and it's python files, which it |
18 |
too should be a sub-package of the catalyst namespace. |
19 |
|
20 |
The main catalyst start script. |
21 |
I am a firm believer that the start script should be a minimal script |
22 |
which imports code from the main package and runs it. I would like to |
23 |
move the current script into the catalyst directory (some editing |
24 |
required) and add a minimal start script to a bin directory to avoid |
25 |
confusion with the catalyst python package dir. I would also split out |
26 |
the confdefaults to a separate defaults file, so that any and all |
27 |
defaults are in one central location. This would make it easy to edit |
28 |
for any future changes rather than chasing through all the code. So all |
29 |
of the current catalyst python code would be moved to files inside the |
30 |
catalyst python package directory. |
31 |
|
32 |
|
33 |
The long term benefit of this restructure is easier maintenance, and the |
34 |
flexibility to create other front-ends to run it. I know most/all of |
35 |
you guys are cli junkies, but with all the working code inside the main |
36 |
catalyst python package, a web interface could be made for it as well as |
37 |
gtk, qt, etc. quis. I'm not saying we would, but the option to is. |
38 |
From what little I know of the releng teams work. A web frontend might |
39 |
be the most logical alternate interface. It would be setup to run on |
40 |
one or more of gentoo's build servers. And with a few more extensions |
41 |
to the code, be able to provide progress status of the build run. |
42 |
|
43 |
For examples of this structure, have a look at current gentoolkit's |
44 |
eclean, enalyze code, layman, mirrorselect, and the emaint rewrite now |
45 |
included in portage. |
46 |
-- |
47 |
Brian Dolbec <dolsen@g.o> |