Hello,

Last week has been a very "paradigmatic" working week. Several problems
urged with the addition of symlinking dependency/inheritance functions. 

sym actions where converted to the form of:

user action bin {
	description "Change Python's Version"
	type sym
	sym python {
		bin python
		target /usr/bin/python 
		prefix /usr/bin/ 
		regexp python([0-9]+\.[0-9]+$)
		sym python-config {
			bin python-config
			destination /usr/bin/python-config
			prefix /usr/bin/ 
			regexp python([0-9]+\.[0-9]+)-config($)
		} python-config
	} python
} bin

Soon urged the need for more complex lexical analysis and started
implementing lex rules and yacc skeleton.

With this step a question bounced into my head. 

Am I reinventing the wheel? 
Why implement lex/yacc to translate a block of code into a python's
block of code?
Why not use plain python in modules?

After discussing with mentor, we decided to adopt python as the base
language for uselect modules.

The final objective is something similar to this:

# Start of Module

# Define the module
module = Module(description = "Python Version Switcher", version =
"0.1", author ="mephx.x@...")

# Define a Symlinking Action
bin = Action (description = "Change Python's Version", type = "sym")

#Define the SymLinks
python = Link(bin = "python", target = "/usr/bin/python", prefix =
"/usr/bin/", regexp = "python([0-9]+\.[0-9]+$")

python-config = Link(bin = "python-config", target =
"/usr/bin/python-config", prefix = "/usr/bin/", regexp =
"python-config([0-9]+\.[0-9]+$")

python.add_link(python-config) # For inheritance
bin.add_link(python) # Adding The Link to the action
module.add_action(bin) #Adding the action to the module

# End of Module

This may seem complex at a glance. But why learn uselect scripting
language when you do modules without even knowing python?

Keep in mind that runnable actions will still be supported and therefore
supporting any scripting language for actions. Python will be the
easiest one as will depend on basic class inheritance and implementation
of functions.

All this lead to the start of a new phase. Define a strong and simple
API definition for all of uselect's capabilities creating the interfaces
easily usable.

uselect's profiles will also be in plain python, using the API of
uselect's Python Module umodule.

Last week had no commits to git due to all this.

I intend to clean up all the "basic (ang buggy) lexical analysis" that
was already implemented and re-implement the new module API during this
week. 

Stay tuned on git for more updates during this week.

http://git.overlays.gentoo.org/gitweb/?p=proj/uselect.git;a=summary 

Cheers,
Sérgio

-- 
Sérgio Almeida - mephx.x@...
mephx @ freenode