[gentoo-dev] Re: Progress on Universal Select Tool

[Sérgio Almeida]

Hello all,

Once again, another productive week. This week's work focused mostly on
profiles. Uprofile's implementation exceeded my expectations and was
much easier than what I thought it would be, the reason: uselect's
simple api.

What's working on uprofile:

* uprofile when called with no arguments, finds current folder profile.
If not present, it lists available profiles.

** Available profiles are profiles other than './uprofile/folder.json'

* Profiles are written in json 

** Why json and not xml? Well, whoever said that xml is human-readable
should reconsider the clause. In need of a markup language, easy bridge
between python and markup, easily human-readable, I have chosen json.

Example:

{"profile": {
	"description": "Sample Profile",
	"author": "mephx.x@×××××.com",
	"version": "0.1",
	"modules": {
		"python": {
			"actions": {
				"bin": [
					"/usr/bin/python2.6",
					"/usr/bin/python2.6-config"
				]
			}
		}
	}
}}

In this profile, uprofile would call module python, action bin with
args: python2.6 and python2.6-config. 

uprofile when called:

mephx - profiledfolder $ uprofile
Setting Folder Profile...
Setting /usr/bin/python2.6 success!
Setting /usr/bin/python2.6-config success!
Folder Profile Set!

* Profiles read modules (from uselect's module dir), actions from
modules, and call's Action.do_action() method with the specified args
list.
** In order to profiles to work properly, arguments cannot be Integers
as in uselect/eselect. All modules's actions which feature profiling
capabilities, need to accept either indexed values, either absolute
string values for specific selection. Why? Example: New python bin
appears in /usr/bin, indexes change, profile gets broken.

* Decided to keep a bin/ and a env.d/ in each .uprofile directory. These
are updated as they normally would via uselect.

* Automatic profile changing in bash can be done via a specially crafted
PROMPT_COMMAND. I'm using this one now:

PROMPT_COMMAND="test -e $HOME/.uselect/env.d/ &&
PROFILE='$HOME/.uselect' ; test -e .uprofile/env.d/ &&
PROFILE='./.uprofile' ; source \$PROFILE/env.d/*"

** This actually changes the profile quite fast and reflects the changes
on $PS1 with the folder name, neat =)

mephx - ~/ $ cd profiledfolder
[folder] mephx - profiledfolder $

** To generate .uprofile/ directory, uprofile needs to be called by
hand. Sourcing env.d/ automatically also updates the user's PATH to that
bin DIR (this is still not implemented) therefore not needing to call
uprofile every time you wish to activate the profile. 


Next steps:

* Finish implementing env actions. (It's now much funnier to test env
actions using profiles)
* Implement uprofile module for uselect as suggested.
* Implement some more modules.

What do you think?

* json modules?
* profile constraints (this is basically adding if's to profiles if we
want profiles to behave differently on certain conditions (hostname,
arch, etc...)

During the next week, I will deploy a properly packed version for
testing. I will also launch a call for modules to every *-eselect dev
and *-config dev as I do not have the time to implement most of the
modules just for testing purposes. Most modules are very easy to do
(symlinking ones) and conversion of eselect to uselect can be done
instantly, yet in an ugly way of still using all eselect's libs.

Keep tuned for more. And stay in school =)

Cheers,
Sérgio
-- 
Sérgio Almeida - mephx.x@×××××.com
mephx @ freenode