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.
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).
shell script and a modern language like Python or Ruby have different use cases. Both have expressiveness, and power, and all, including the shell, very different applicability.
This project is far from a toy; there's a complete MQTT client written in it, bish-bosh[1], and swaddle (see comment below). I wouldn't build a webserver in it, but I would build command line wrappers of all those REST APIs out there so I don't have to install gems and eggs and whatever else to just get stuff done. shellfire is minimally dependent.
shellfire exists because installing Ruby and Python and all their dependencies is simply not an option for minimal bare metal servers and routers. Because there are far too many 'toy' shell scripts out there that aren't robust. Because the shell is the glue we need for out big ticket applications. Because I really loathe having to depend a VM configured and setup and snapshotted.
Performance is not a goal, not should it be for any scripting language. If you need performance, write in C or perhaps Java, although V8 is getting closer all the time.
And there is not dependency. shellfire deliberately discourages the model of 'install framework in /usr/lib'. It just doesn't work. But it does support working nicely with git-based dependencies as you develop; you can even deploy as nothing more than a git export, if you so choose.
Thank you, that's appreciated. I want it to not be complicated in use - but like anything new, there's always that wall of initial confusion. It's early days for all of it, and this is taking a very different approach with the shell: it treats it like a proper language. Arguably, one that needs much more discipline than first appears.
Everyone has a different learning style - perhaps the tutorial will help? Or just looking at a real use case - try bish-bosh at https://github.com/raphaelcohn/bish-bosh. Let me know if there's a better way of explaining it.
If there's enough folks interested, maybe we could run an interactive tutorial or IRC session?
