1 |
Michael, |
2 |
|
3 |
> Yeah, this indeed could work! |
4 |
> |
5 |
> But there is one restriction: |
6 |
> This .uselect folder must be able to be checked in into some VCS, so it |
7 |
> should not contain symlinks, but plain (text?) files only. |
8 |
> We also want to use this on Windows based filesystems where symlinks |
9 |
> don't work at all. |
10 |
> |
11 |
|
12 |
Do we really need more than one file? |
13 |
|
14 |
> Ohw, I do have another requirement: |
15 |
> We do check-out/compile/develop/run/test the same package on different |
16 |
> hosts and platforms. Each of these hosts might require slightly |
17 |
> different settings. ATM, the package's environment script handles this |
18 |
> by acting differently based on `hostname` and `uname` or "${chost}". |
19 |
> Ohw, it even does different settings based on the username (`id -un` or |
20 |
> `whoami`), because in production these projects usually run under a |
21 |
> specific user with less restrictive settings than for developers. |
22 |
> |
23 |
|
24 |
Checklist: |
25 |
* Hostname |
26 |
* Uname |
27 |
* {$chost} |
28 |
|
29 |
Mmm... Maybe we can simplify this with a parameter like: |
30 |
|
31 |
# eval something |
32 |
eval "hostname" "superhost" |
33 |
what |
34 |
to |
35 |
do |
36 |
# end something |
37 |
|
38 |
Then if command "hostname" outputs "superhost" we know "what-to-do". |
39 |
|
40 |
This way it would get ultra versatile. |
41 |
|
42 |
> What if there is some hierarchy in .uselect/ much like the profiles in |
43 |
> gentoo-x86 tree, using some kind of 'parent' files to inherit/override |
44 |
> settings for this one project, where 'parent' can contain something like |
45 |
> $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)? |
46 |
> |
47 |
|
48 |
Would this really be necessary? We can define hierarchy into a |
49 |
single .uselect file. Even the use of folders (folder .uselect/) isn't |
50 |
necessary. I think a single file can handle all this... Lets see an |
51 |
example: |
52 |
|
53 |
# profile something |
54 |
version '0.1' |
55 |
do this 1 |
56 |
do that 1 |
57 |
|
58 |
# eval hostname |
59 |
eval "hostname" "supermachina" |
60 |
|
61 |
do that 2 # this should override the prev. value |
62 |
|
63 |
# eval whomai <- inheritance inside eval hostname |
64 |
eval "whoami" "mephx" |
65 |
|
66 |
do more of this |
67 |
do more of that |
68 |
|
69 |
# end whoami |
70 |
# end hostname |
71 |
|
72 |
# eval uname |
73 |
eval "uname" "Linux" |
74 |
|
75 |
do this 3 <- override the overridden =) |
76 |
|
77 |
# end uname |
78 |
|
79 |
|
80 |
The actions to be done like "do this 3" are a simple call to uselect |
81 |
using module "do" and action "this" with "3" as parameters. |
82 |
|
83 |
Remember that profile creation/storing/managing should be automatic and |
84 |
nothing would need to be written by hand. By other words, create a basic |
85 |
profile automatically using your currently running settings and then |
86 |
alter the profile with the util to add constrains to it. Remember that |
87 |
all the machines that this profile is read would need to have the same |
88 |
uselect modules into it's /usr/share/uselect/modules or similar. |
89 |
|
90 |
> I'm unsure if managing different settings based on hostname, uname/chost |
91 |
> and username (the inheritance tree) is uselect's job. It eventually |
92 |
> should optionally listen to some cmdline-parameter or environment- |
93 |
> variable where to look for the uselect settings instead, which could be |
94 |
> stored and regenerated using such profile hierarchy mechanism/utility. |
95 |
> Or even the whole uselect settings optionally come from stdin (and go to |
96 |
> stdout), to be managed/stored within that profile hierarchy. |
97 |
> |
98 |
> Ha! This kind of inheritance tree could be a solution for my long |
99 |
> standing bug here to simplify our way too complex environment script... |
100 |
> |
101 |
|
102 |
This is a basic idea from softenv so it has has it's place into uselect. |
103 |
The question now is, bloat it all into uselect or create a uprofile |
104 |
util? I like the idea of having to use only uselect for basic profiling |
105 |
and using uprofile for further managing. |
106 |
|
107 |
> Ah, don't forget to put a version number as the very first value into |
108 |
> the uselect settings, to avoid backwards compatibility issues in the |
109 |
> future. And when uselect settings can be read from stdin (stored in |
110 |
> simple text files), this version number could occur multiple times |
111 |
> there, as the stored files simply will be concatenated. And subsequent |
112 |
> values might override previous ones then. |
113 |
> |
114 |
|
115 |
Mmmm... As you wrote I realized: Complain if module versions are |
116 |
different is not a bad idea at all... |
117 |
|
118 |
Why would we need more that one profile file per project/folder anyway? |
119 |
|
120 |
|
121 |
> Uh, so many strange ideas! |
122 |
> More of them? |
123 |
> |
124 |
|
125 |
Keep 'em coming! Thanks! |
126 |
|
127 |
Cheers, |
128 |
Sérgio |