raphcohn

Cool. fpm's a good tool, but it requires a lot of command line fu, and isn't source control friendly. One of the reasons for swaddle was to get more of this stuff into source control and less into complex build scripts. One of the others was a major headache we once had with broken ruby versions on build servers breaking things like fpm (especially when multiple versions were needed). Swaddle fixes this, too.

No, it's not like Python/Ruby/etc dependencies. You use your own git; dependencies are submodules in your git repo. shellfire deliberately is not designed to be installed in `/usr/lib` or wherever. In this sense, it's more like Go. Going down the git route gives fine-grained control over which dependency versions one uses.

This makes development completely independent of the `/usr`, etc of the machine your own. If you clone your repo from your laptop to someone else's desktop, no need to to install deps, no need even for a working network env - valuable if you're in one of those places that breaks Ruby because they uses a Windows proxy (eg most UK Gov setups).

You don't have to fatten; you can just deploy by exporting your git repo. That sort of route would be perfectly acceptable for most enterprise work. Still no need to install deps, as everything is relatively-pathed.

Thank you. It's almost impossible to have a set of 'shell functions' that are entirely independent of one another, once you move beyond a few special cases. That said, this is as near to copy and paste as you can get - it's Git based, and the idea is you just add groups of functions as git submodules. You can test and deploy as you go, and then, when you're ready, fatten the script and release it.

The shell needs to be understood. There's no doubt it's an old looking-language to most people, but that's why we should treat it with the same discipline as anything else. I'd agree that the shell can be obscure. Wherever possible, shellfire tries to make things explicit, not obscure through good naming; hence the reams of functions on core/variable to do simple things, eg core_variable_startsWith rather than having to figure the weird looking ${var?/:} syntax.

Thank you. There's lots of good stuff in bashmenot. Is there anything you think you'd like to add to shellfire to make it even better?

Perhaps - I hadn't yet even thought of dreaming the similitude of it taking off. Thanks (;-). But shellfire wouldn't be as invasive. Each shellfire script stands alone, a bit like a statically-compiled C executable. Of course, there are still call outs to third-party binaries - but that ordinarily shouldn't be much more than busybox or coreutils, grep, awk and sed, with may be curl. And one can, with shellfire snippets, even embed binaries in the shell script... although whether that's wise is another discussion.

The proof in the pudding will be trying to make libertine linux use it - a not even started project of mine to build a minimal, net-bootable linux with an immutable file system (upgrade == reboot a new image).