Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Sérgio Almeida]

On Tue, 2009-05-26 at 22:04 +0200, Tiziano Müller wrote:
> Am Montag, den 04.05.2009, 22:01 +0100 schrieb Sérgio Almeida:
> > Gentoo Dev's,
> >
> > My name is Sérgio Almeida, I am Portuguese and I am a student for this
> > year's Google SoC coding the Universal Select Tool project for Gentoo
> > being Sébastien Fabbro (bicatali) my mentor.
> >
> > Abstract:
> >
> > Universal Select Tool is an utility to manage system configuration.
> > This tool is similar to the unmaintained eselect utility of Gentoo or
> > Exherbo's eclectic. The idea is to create a tool that  manages both
> > system settings and user settings with profile creation possibilities.
> > The utility will use mostly concepts from "modules", "softenv", and
> > both "eselect" and "eclectic".
> >
> > My initial proposal does not get in-depth with implementation details
> > and I need to make some decisions as soon as possible. Implementation
> > language will be python as it is easy to maintain, easy to code and
> > faster and more flexible than bash. See attachment for more details.
> >
> > Besides introducing myself, the purpose of this e-mail is a
> > call-to-ideas to all Gentoo developers, mainly all eselect-* and
> > *-config developers.
> >
> > Here are the main interest ideas:
> >
> > * keep eselect structure of modules - actions
> >
> > * symlinking, environment and aliases actions can consist of something
> > like:
> >
> >         # module moo comments
> >         description "Example Module description"
> >         version "Example Module Version"
> >         author "moo@××××.moo"
> >         # action system moo
> >         description "Moo Action Description"
> >         symlink "regexp" "regexp"
> >         env "regexp" "regexp"
> >         alias "regexp" "regexp"
> >         # end moo
> >
> > These should get the job done for most of the modules and opens the door
> > to automatic module creation prior to a successful emerge (if some USE
> > flag set)
> >
> > * Actions that consist of code blocks that support any scripting
> > language (what about binaries?) to do more complex actions (full module
> > example):
> >
> >     # module moo comments
> >         description "Example Module description"
> >         version "Example Module Version"
> >         author "moo@××××.moo"
> >
> >         # action user moo
> >         description "Example Module will moo for any user"
> >         type runnable
> >         runner /bin/bash
> >         # file moo.bash
> >         #!/bin/bash
> >         do_moo() {
> >         	echo "This is the Example Module mooing"
> >         }
> >         do_moo()
> >         # end moo.bash
> >         # end moo
> >
> > * actions can be run system-wide and per-user:
> >         # action user moo
> >         # action system moo
> >
> > * automatic module loading and profile management can be managed by some
> > env.d python scripts that are user-aware and follow some database
> >
> > I've been given this difficult task of unifying all of these tools
> > together and as you all can understand, I won't be having the time to
> > read through all eselect-* modules and *-config utilities code.
> >
> > Please drop me a line here or at freenode if you have anything to add to
> > these ideas or have any further ideas that can help me on this project.
> > Thank you all in advance.
>
> What I'd like to see is the possibility to
> ... localize messages (will be difficult since modules need translations
> as well, but maybe you find a way :)
> ... encapsulation of methods to set/list/change such that instead of a
> CLI- a NCurses- or GUI-Frontend could be developed.
>
> Cheers,
> Tiziano
>

Hello,

These are the reasons of my current prototype refactoring phase. All
this will be possible.

Thanks!

Cheers,
Sérgio