Are you pulling my leg? Even Perl is more succinct & readable
Bash scripts, especially when utilizing pipes, are really hard to beat for certain types of operations.
Whether those use cases apply to edeliver is another conversation entirely, but donât knock Bash.
Yeah, definitely Bash pipes are cool. But itâs only a way to call other programs. When you start to write code in Bash, things getting much worse very soon. And Edeliver code is not an exception. For example, try to figure out how to make Edeliver to set Erlang and Elixir versions on the build server through kerl & kiex, and you will get what I mean.
Iâm not going to advocate for doing anything particularly complex with it, donât get me wrong there. Just depending on the situation, it can be great.
Perl often looks like line noise.
Now I like perl, can do magic in that language (it was the best thing on the old SCO Unix servers I managed), but the fact things like the âtypesâ of things change based on things like hidden context is crazy.
+1
Or ZSH, ZSH is a more âsaneâ bash in how it handles expansions and all, but is mostly identical. ^.^
Why doesnât it just use docker for the builds and deployment, or asdf or so? Deploying with docker is sooo simple and you donât have to worry about platform-specific oddities.
/me hasnât used Edeliver as just deploys via rsync and a systemd script
I guess we shouldnât muddle up Bash as a programming language, and as a shell. Although they are highly coupled, but in any caseâŠ
Whatâs the difference between asdf & kiex usage? In general your question looks like âWhy do we need Edeliver?â, but itâs a bit odd question for the topic about Edeliver
asdf
actually wraps kerl (among other things) to give a simple interface for integrating all of those (and a lot more things), and having it acquire and globally or locally set the versions is pretty trivial (even more so in docker, but you donât need any management thing if using docker, it should just deploy using docker).
But a big thing if deploying on the base OS is that you can set an erlang/elixir version local and specific to a given directory tree.
No problems with BASH itself - itâs a tool as much as Elixir. Itâs just happened that BASH became a maintanance nightmare because itâs not covered with tests and almost none is interested in learning it, including myself. It might be good in situations when there would be a person who will look after it but itâs not a case here.
Bash is a DSL for calling other programs. Edeliver was originally written in bash because calling other programs is mostly what it does (but the logic just got gradually more convoluted, so it isnât just calling other programs anymore, so it needs better).
If I was God-Emperor of the world, Iâd use PowerShell But On The BEAM Instead Of .NET. Administrative stuff would work like this:
$application = "myapp"
$version = "1.0.3"
$servers = "server1.localdomain","server2.localdomain"
$directory = "path/to/release"
$releaseFilename = "$application-$version.tar.gz"
$releaseContents = Get-Content $releaseFilename
$username = "notriddle"
$servers | foreach {
Invoke-Command -ComputerName $_ -Credential $username -ScriptBlock {
cd $directory
Set-Content -path $releaseFilename -value $releaseContents
tar -xvf $releaseFilename # notice how I can just call "tar" like this and it just works
./bin/$application upgrade
}
}
Yes, itâs the unholy offspring of bash, Perl, and C#. I love it anyway.
It has all the conceptual gunk already there for calling into other applications easily (calling a command in PowerShell will consult the $Env:PATH
and produce a pipeable stream split by lines, just like bash does) while simultaneously allowing you to have actual manipulatable thingies like lists ($servers
is a list, which is a stream in PowerShell just like lists are streams in Elixir) and PIDâs (not demonstrated here, because weâre not really doing anything that needs it, but it could be done).
Iâm not sure if writing a PowerShell â Core Erlang compiler would be the absolute best possible use of our time, thoughâŠ
I guess with a good unit and integration tests coverage it can be pretty much any scripting language
But so far I found Bootlegâs approach the best - a bunch of mix tasks and sshkit.ex