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