[pherocity_]

I love the idea, I've also been frustrated, and there has been chicken and egg problems which this may help with. That said, the quote:

> "And lastly, because we're fed up with having to install half-an-universe's worth of Ruby, Python and Perl to bootstrap our servers or run CI jobs"

If this takes off, some will use it some won't, and we'll be stuck installing a "half-an-universe's worth of Ruby, Python, Perl, and Shellfire scripts to bootstrap our servers or run CI jobs"

[raphcohn]

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).

[voltagex_]

Hey, if I can pack your future Linux distro into one (kernel+initrd) PXE/GRUB bootable file, system rescue just got a lot easier.

[mietek]

So, this is pretty cool. I am in particular impressed how thorough your curl wrapper is. Mine is pretty basic in comparison:

https://github.com/mietek/bashmenot/blob/master/src/curl.sh

[raphcohn]

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?

[AceJohnny2]

Yeah, I'm ambivalent about this. (For some background, I used to hate Perl until I had to write some non-trivial shell scripts, then I realized Perl was a godsend compared to shell).

We've long been at the point where you can expect Perl and Python to be installed (Perl is required by the Debian's base tools, and Python by Redhat's).

You may not have the libraries you need at the version you need, and it's a shame that neither system has a convenient way to address that (Python virtualenv remains a hacky solution IMHO).

I was initially enthused by Shellfire's offering but, come to think of it, all it's doing is bringing SH scripting to some level with Perl or Python... but, as you point out, we have those already.

[Florin_Andrei]

> I used to hate Perl until I had to write some non-trivial shell scripts, then I realized Perl was a godsend compared to shell

If the job requires one page of code or less, use shell. If it requires more than one page of code, use Python or whatever. Simple as that.

I still hate Perl anyway - source code obfuscation by design is a terrible thing to do to your brain.

[JadeNB]

> If the job requires one page of code or less, use shell. If it requires more than one page of code, use Python or whatever. Simple as that.

The problem with this simple guideline is that tools grow, so what was well less than a page becomes much more—and each small increment is too small to justify a complete re-write, so eventually you wind up with a huge shell-script monster.

[AceJohnny2]

That's mostly my heuristic as well, except there's a sweet spot for Perl somewhere in the middle.

Python has a upgrade problem. We're still running a bunch of CentOS 5.5 machines which depend on Python 2.4. In my org, we still have scripts littered around that expect a later version of python, but are executed from just "#!/usr/bin/python" instead of "python2.7". which fails on those old CentOS machines, on which you can't just set a newer version of Python as default because that'll break many system utilities.

Also, Perl's syntactic sugar for regular expressions turns out to be very useful (and I say this after years of grumbling against it).

[zokier]

What is wrong with virtualenv?

[AceJohnny2]

It's not path-relative: I can't copy an env from one dir to another. It's an external tool that you need to enable separately from your execution, when really it should've been part of Python's base binary (resolving libs from the CWD to user libpath to system libpath), to name just a couple issues.

[csirac2]

virtualenv appears to be a giant, epic work-around for... what exactly? Somehow, perl managed to achieve the same thing with the PERL5LIB envar. And did it in a far more portable, reusable and repeatable way.

[AceJohnny2]

Exactly. I love Python for many other reasons, but how they still haven't managed to fix local vs user vs system libraries, when pretty much every other language has, and think virtualenv is an acceptable solution, is beyond me.

Of course, since they have many geniuses working on their codebase, I assume the problem must actually be pretty fundamental and tricky.... right?