On 07/01/2015 23:25, Avery Payne wrote:
> The goal is the same but the emphasis has changed. This will be considered
> a fall-back feature for those systems that do not have such a tool
> available, or have constraints that force the continued use of a shell
> launcher. It is the option of last resort, and while I think I can make it
> work fairly consistently, it will come with some warnings in the wiki. For
> Laurent, he wouldn't even need to lift a finger - it fully complies with
> his desires out of the box. ;-)
Eh, you don't have to. It's not for me, it's for the users. I honestly
believe it's better this way, but you may disagree, and as long as you're
the one writing the code, you're the one having the say.
> Unfortunately, the envdir tool, which I use to abstract away the daemons
> and settings, only chain-loads; it would be nice if it had a persistence
> mechanism, so that I could "load once" for the scope of the shell script.
Here's an ugly hack that allows you do that using envdir:
set -a
eval $({ env; envdir ../.env env; } | grep -vF -e _= -e SHLVL= | sort | uniq -u)
set +a
It only works for variables you add, though, not for variables you remove.
Also, be aware that it considerably lengthens the code path... but not
significantly more than dependency management in shell already does. :P
> Sshh! Don't talk too loudly...you'll expose my secret plan! :-) But
> thanks for saying that, and you are right. The drive of the project is to
> increase accessibility of the frameworks, and in doing so, increase
> adoption. Adoption will lead to feedback, which leads to improvements,
> which drives development forward, increasing accessibility, etc. in a
> continuous feedback loop.
This is a very laudable goal, if you think the way to getting into distros
is this kind of accessibility.
I'm of the opinion that packagers will naturally go towards what gives
them the less work, and the reason why supervision frameworks have trouble
getting in is that they require different scripting and organization, so
supporting them would give packagers a lot of work; whereas sticking to
the SysV way allows them not to change what they already have.
Especially with systemd around, which they already kinda have to convert
services to, I don't see them bothering with another out of the way
packaging design.
So, to me, the really important work that you are doing is the run script
collection and standardization. If you provide packagers with already made
run scripts, you are helping them tremendously by reducing the amount of
work that supervision support needs, and they'll be more likely to adopt it.
It's a thankless job, and I understand that you want to have some fun by
playing with a dependency manager ;)
--
Laurent
Received on Thu Jan 08 2015 - 02:53:44 UTC