Michael,
> Yeah, this indeed could work!
>
> But there is one restriction:
> This .uselect folder must be able to be checked in into some VCS, so it
> should not contain symlinks, but plain (text?) files only.
> We also want to use this on Windows based filesystems where symlinks
> don't work at all.
>
Do we really need more than one file?
> Ohw, I do have another requirement:
> We do check-out/compile/develop/run/test the same package on different
> hosts and platforms. Each of these hosts might require slightly
> different settings. ATM, the package's environment script handles this
> by acting differently based on `hostname` and `uname` or "${chost}".
> Ohw, it even does different settings based on the username (`id -un` or
> `whoami`), because in production these projects usually run under a
> specific user with less restrictive settings than for developers.
>
Checklist:
* Hostname
* Uname
* {$chost}
Mmm... Maybe we can simplify this with a parameter like:
# eval something
eval "hostname" "superhost"
what
to
do
# end something
Then if command "hostname" outputs "superhost" we know "what-to-do".
This way it would get ultra versatile.
> What if there is some hierarchy in .uselect/ much like the profiles in
> gentoo-x86 tree, using some kind of 'parent' files to inherit/override
> settings for this one project, where 'parent' can contain something like
> $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
>
Would this really be necessary? We can define hierarchy into a
single .uselect file. Even the use of folders (folder .uselect/) isn't
necessary. I think a single file can handle all this... Lets see an
example:
# profile something
version '0.1'
do this 1
do that 1
# eval hostname
eval "hostname" "supermachina"
do that 2 # this should override the prev. value
# eval whomai <- inheritance inside eval hostname
eval "whoami" "mephx"
do more of this
do more of that
# end whoami
# end hostname
# eval uname
eval "uname" "Linux"
do this 3 <- override the overridden =)
# end uname
The actions to be done like "do this 3" are a simple call to uselect
using module "do" and action "this" with "3" as parameters.
Remember that profile creation/storing/managing should be automatic and
nothing would need to be written by hand. By other words, create a basic
profile automatically using your currently running settings and then
alter the profile with the util to add constrains to it. Remember that
all the machines that this profile is read would need to have the same
uselect modules into it's /usr/share/uselect/modules or similar.
> I'm unsure if managing different settings based on hostname, uname/chost
> and username (the inheritance tree) is uselect's job. It eventually
> should optionally listen to some cmdline-parameter or environment-
> variable where to look for the uselect settings instead, which could be
> stored and regenerated using such profile hierarchy mechanism/utility.
> Or even the whole uselect settings optionally come from stdin (and go to
> stdout), to be managed/stored within that profile hierarchy.
>
> Ha! This kind of inheritance tree could be a solution for my long
> standing bug here to simplify our way too complex environment script...
>
This is a basic idea from softenv so it has has it's place into uselect.
The question now is, bloat it all into uselect or create a uprofile
util? I like the idea of having to use only uselect for basic profiling
and using uprofile for further managing.
> Ah, don't forget to put a version number as the very first value into
> the uselect settings, to avoid backwards compatibility issues in the
> future. And when uselect settings can be read from stdin (stored in
> simple text files), this version number could occur multiple times
> there, as the stored files simply will be concatenated. And subsequent
> values might override previous ones then.
>
Mmmm... As you wrote I realized: Complain if module versions are
different is not a bad idea at all...
Why would we need more that one profile file per project/folder anyway?
> Uh, so many strange ideas!
> More of them?
>
Keep 'em coming! Thanks!
Cheers,
Sérgio
