[gentoo-catalyst] More proposed Catalyst changes

[Brian Dolbec <dolsen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

While making changes to catalyst for the tree move I noticed that there
is in my view a serious design flaw in the way the python modules for it
are laid out.

The modules directory has no __init__.py so is not automatically
recognized by python as a directory containing python code...  So, there
is code in the main catalyst script to insert that path to it's modules
so that they are found.

Inside that modules directory is the main catalyst python package
directory.

These two directories are reversed.  The modules directory should be
nested inside the catalyst directory and have an __init__.py file so
that they are properly and automatically inside the catalyst namespace. 

The same is true of the arch directory and it's python files, which it
too should be a sub-package of the catalyst namespace.

The main catalyst start script. 
  I am a firm believer that the start script should be a minimal script
which imports code from the main package and runs it.  I would like to
move the current script into the catalyst directory (some editing
required) and add a minimal start script to a bin directory to avoid
confusion with the catalyst python package dir.  I would also split out
the confdefaults to a separate defaults file, so that any and all
defaults are in one central location.  This would make it easy to edit
for any future changes rather than chasing through all the code.  So all
of the current catalyst python code would be moved to files inside the
catalyst python package directory.


The long term benefit of this restructure is easier maintenance, and the
flexibility to create other front-ends to run it.  I know most/all of
you guys are cli junkies, but with all the working code inside the main
catalyst python package, a web interface could be made for it as well as
gtk, qt, etc. quis.  I'm not saying we would, but the option to is.
From what little I know of the releng teams work.  A web frontend might
be the most logical alternate interface.  It would be setup to run on
one or more of gentoo's build servers.  And with a few more extensions
to the code, be able to provide progress status of the build run.

For examples of this structure, have a look at current gentoolkit's
eclean, enalyze code, layman, mirrorselect, and the emaint rewrite now
included in portage.
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]