FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Portage Developer

 
 
LinkBack Thread Tools
 
Old 03-28-2010, 09:26 AM
Brian Dolbec
 
Default proposed emaint changes

I have recently been doing a re-write of eclean and one of the problems
to address was the need to run "emaint fix packages" when doing any
cleaning of the packages directory. Since eclean and emaint are coded
in python, I looked into importing the emaint code and running it from
within eclean. Currently emaint is an all inclusive script without any
easily import-able modules. Asking Zac, he stated that it would be fine
to change that to a cli script and library.

So, going through the code, I found it pretty much was already
modularized but just stuck together in the one file. In there was also
a TODO message:


# TODO: Create a system that allows external modules to be added without
# the need for hard coding.
modules = {
"world" : WorldHandler,
"binhost":BinhostHandler,
"moveinst":MoveInstalled,
"movebin":MoveBinary,
"cleanresume":CleanResume
}


So having a bit of experience with porthole's plug-in system, I took it
upon myself to create a small plug-in system. I also designed it to load
as little code as possible. With this plug-in system emaint actually
runs slightly faster than the original script. The only changes
being done were to use the plug-in system and independent module files
containing the original unmodified module class. I believe the
speed increase is due to python not having to load as much script, as
only the module's __init__.py for all modules is loaded initially and
then the requested operation module file is loaded.

I think you will find this plug-in system very straightforward, perhaps
a little overkill for emaint. But it does offer a number of advantages
including less code changes to add/remove modules, full module usability
by other apps, etc.. Fully re-useable plug-in system for other apps
(when complete).


I have a bzr branch of portage's svn trunk with the modified emaint. It
is fully functional for your testing and review of the code. I do have a
little more work to do on it. So far I have not modified the code to
make use of the 'functions' and 'func_desc' data provided by the modules
__init__.py module_spec dictionary. It is currently relying on the
original hard coded ['check', 'fix'] functions in the different module
classes. It has also been suggested to make the modules dictionary a
LazyLoad dictionary instead.


I have a bzr branch available:

bzr co http://dev.gentooexperimental.org/~dol-sen/bzr/portage-trunk/

If I did it correct, I also have migrated it to a git branch too:

git remote add emaint http://dev.gentooexperimental.org/~dol-sen/git/portage.git/
git fetch emaint
git branch emaint

and test/review it.


I have attached 2 module __init__.py's and the module.py file for
your perusal without the need to checkout a copy of my repo.

For those of you getting a bzr checkout or git remote to test. Try
moving modules in and out of the modules dir and then run emaint -h.
Also the vdbkeys module is old and no longer usable, so will not be
included in the final version should it be approved and implemented. I
include it here so you can see how easily modules can be added/removed.

I have also coded up a dummy module demonstrating the ability to
automatically change the class returned for a module name according to
an environment variable setting. But there are a number of other ways
that it could use too.
--
Brian Dolbec <brian.dolbec@gmail.com>
 

Thread Tools




All times are GMT. The time now is 07:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org