1 |
Sebastian, |
2 |
|
3 |
> It seems to me that the original langauge is "static"/"descriptive" |
4 |
> while Python is not. Why not move to XML or JSON (former seems more |
5 |
> common with Gentoo) instead of Python? Think about how much easier it |
6 |
> is to pull information from metadata.xml than from .ebuild files - it's |
7 |
> the same difference in your case. |
8 |
|
9 |
I considered XML/JSON in this decision and did not even discussed it |
10 |
with my mentor. This is indeed not and abandoned idea as I explain |
11 |
below. |
12 |
|
13 |
> |
14 |
> You know much better where you want to go with this than I do, but |
15 |
> please triple-check this move, as you cannot go back. |
16 |
> |
17 |
|
18 |
I'm in no position to chose the path to take but for now python still |
19 |
seems the chosen "vehicle". Remember that using XML/JSON for modules |
20 |
would never need a re-write from uselect but would only be an extension |
21 |
to the module system. Let us see. |
22 |
|
23 |
In uselect everything are objects. |
24 |
|
25 |
Module is a class |
26 |
Action is a class |
27 |
|
28 |
Module(s) have Action(s) |
29 |
|
30 |
Actions are interfaces to many kinds of actions, Sym, Path, Runnable |
31 |
|
32 |
Sym and Path actions have Link(s) |
33 |
|
34 |
Runnable actions have code and know how to execute it. |
35 |
|
36 |
Therefore the backend scenario (object space) is the same as the new |
37 |
suggested module syntax. |
38 |
|
39 |
Basically this decision is not adding a feature. It is abandoning the |
40 |
"uselect syntax" thus removing a feature. |
41 |
|
42 |
This will help during development as parsing is the task that has been |
43 |
more time consuming during uselect's development. |
44 |
|
45 |
With this uselect will have an open interface for extension to any |
46 |
markup language that comes in handy in module readability/programming. |
47 |
|
48 |
> |
49 |
> Thanks for listening, |
50 |
> |
51 |
> |
52 |
> |
53 |
> Sebastian |
54 |
> |
55 |
|
56 |
I thank you. Will now add the markup language support to the to-do list, |
57 |
not to implement right away but to have in mind while expanding the API. |
58 |
|
59 |
Cheers, |
60 |
Sérgio |
61 |
|
62 |
-- |
63 |
Sérgio Almeida - mephx.x@×××××.com |
64 |
mephx @ freenode |