NIH If you are looking for a DSL that uses shell: https://www.cdi.st/cdist-why.html It's already mature and used in production at various places/datacenters.
"cdist is written in Python" - that's a significant difference
Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
61–70 of 86 posts
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#62NIH If you are looking for a DSL that uses shell: https://www.cdi.st/cdist-why.html It's already mature and used in production at various places/datacenters.
"cdist is written in Python" - that's a significant difference
In my experience, Python is just as brittle, because it just as much lacks static checking. (Though of course mypy helps with the basics, and there ought to be a test or dry-run mode in every "devops" system, but I have no idea what cdist does.)
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#63Earlier quoted context omitted.
Y'all just have bias against the string system. Writing decent code in bash is just as possible as any other language. I stick to POSIX sh but same difference.
"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays" http://www.oilshell.org/blog/2016/11/06.html
Yeah I should clarify; I think it's well past the time of sh.
Still, sh is unrivaled for portability and brevity/velocity; I wouldn't swap virtually any the shell scripts I've written for python scripts. I think sh is a decent and often well-suited tool if you can manage to wield it properly (not a straightforward endeavor).
I look forward to checking out oilshell though, so thank you~
Edit: FWIW for arrays in POSIX sh I generally only use:
set -- a b c
echo $#
echo "$1"
shift
echo "$@"
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#64Bash should be recognized as the tech equivalent of asbestos.
In config management, I often think to myself as I'm trying to figure out how to express in the DSL some simple thing, that I'd rather just write the bash. Why should I learn each new fashionable DSL just to have it translate back to the shell commands I spent so long translating into the DSL? It's a game of telephone.
This is a cool/fun project, but I've got to say, if I'm troubleshooting a production issue I'd so rather be dealing with the (shorter) generated bash equivalent than the bashable DSL in the example they have there.
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#65Bash should be recognized as the tech equivalent of asbestos.
Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#66Earlier quoted context omitted.
Y'all just have bias against the string system. Writing decent code in bash is just as possible as any other language. I stick to POSIX sh but same difference.
Why POSIX sh? Bash is everywhere. I once in my career had access to and needed jobs performed on a mainframe with AIX running. It had bash, it had ruby, it had day, it had fish shell. I couldn't and can't understand why people insist on asceticism (Korn shell, POSIX sh) when nicer options are available.
dash is 10% of the size of bash. You don't need the interactive features when running shell scripts, and the few "extra" features are pretty crap anyway (arrays? yeah right).
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#67Earlier quoted context omitted.
> complex logic encoded into YAML This should stop too.
What's the answer then?
A declarative configuration that specifies deployment state, using a powerful language like Cue[1], and a reconcilation mechanism - written in a real programming language - that ensures that real state matches declared state (like k8s).
The Ansible/Puppet/Chef/... approach of establishing and then haphazardly poking at highly stateful server state is fundamentally flawed. Top-tier systems engineering organizations like Google figured this out a decade ago and moved to mostly stateless deploments that can be redeployed and reconfigured with confidence. There's always some state you can't get rid of, but it must be minimized to reduce the "entropy tax".
[1]: https://cuelang.org
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#68Are there any other Ansible alternatives that avoid the whole YAML mess?
I haven't used Puppet for 6 years but it had its own DSL. But I'm not sure if that's any better than yaml and it's much more work to set up and requires a client installed on each target machine.
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#69Bash should be recognized as the tech equivalent of asbestos.
In config management, I often think to myself as I'm trying to figure out how to express in the DSL some simple thing, that I'd rather just write the bash. Why should I learn each new fashionable DSL just to have it translate back to the shell commands I spent so long translating into the DSL? It's a game of telephone. This is a cool/fun project, but I've got to say, if I'm troubleshooting a production issue I'd so r…
My answer: so that other people can actually work with the scripts you write.
Some DSLs are definitely a waste of time (hello Jenkins!), but in the anecdotal experience of myself and literally everyone I’ve talked to, Ansible is massively easier to learn than Bash. I’ve had junior devs (who don’t even know Python!) writing and maintaining useful tasks within minutes, and that’s not even an exaggeration.
Shell scripts, IME, work great until you need a certain amount of logic, and then they become a collapsing Death Star of edge cases and tribal-knowledge pitfalls.
Re: Bashible: An Ansible-inspired deployment/automation tool written in Bash DSL
#70Earlier quoted context omitted.
Could you elaborate on how and why s-expression solve address the issues of yaml-based DSL? Thanks
S-expressions have keywords, and don't require commas between list elements. That alone goes a _long_ways towards making s-expression based languages way more readable/writable than a similar datastructure encoded in something like JSON or YAML. Here's an example of a JSON coded query taken from a PuppetDB tutorial (PuppetDB uses a very lispy query language): ["and", ["=", "type", "User"], ["=", "title", "nick"]] And…
Thanks for example and explanation, this makes good sense. I apologize if this is a naive question but is there a reason we don't see configuration management taking advantage of S-expressions?