bearclaw VS executable-dist-plugin

why?

Every year I challenge myself in some new way, this year it is to push one project per week. You might recognize my static site generator [0] or my releaser for go [1] from previous posts as one of these weekly projects. If you want to join me in doing this, it's been a blast and I highly recommend it! Maybe we can chat on the bbs about it :)

[0] - bearclaw tiny static generator - https://github.com/donuts-are-good/bearclaw

[1] - release.sh release builder for go - https://github.com/donuts-are-good/bearclaw

need:

I'd love a few co-conspirators, or even some new friends for the bbs software or the bbs itself. A lofty nice-to-have goal is meeting a few other similarly motivated people to conspire with on a weekly basis. If that's you, drop me a line!

goals:

I have about half of an admin interface endpoint pushed up, which I'd like to finish. I realized mid-commit that I'd lacked some other material in a previous commit, and in pushing it up, I ended up pushing half the admin feature. Stay tuned for that.

I made a cool program for you Go stuff that will check all the supported OS and ARCH combos for your code and compile them all. You just do `release --name "mycoolprogram" --version "0.1.0" and it will output all of your labeled release binaries for every platform your code supports.

check it out! https://github.com/donuts-are-good/release.sh You can see it at work here for this simple markdown blog generator I made, which sports about 39 different platform combos https://github.com/donuts-are-good/bearclaw/release/latest

> tiny static site generator w/ rss https://bearclaw.blog

bearclaw.blog redirects back to source repo[0] on GitHub.

Should not it be a redirect to GitHub Pages site?

[0] https://github.com/donuts-are-good/bearclaw

I feel like i'm taking crazy pills (at a low dose) when i read this stuff.

I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1].

That is one step more than deploying a single binary, but it's a trivial step, and both steps are done by a release script, so there is a single user-visible step.

The additional pain associated with deploying a tarball rather than a single binary is negligible. It simply is not worth worrying about [2].

But Go enjoyers make such a big deal of this single binary! What am i missing?

Now, this post does talk about Docker. If you use Docker to deploy, then yes, that is more of a headache. But Docker is not the only alternative to a single binary! You can just deploy a tarball!

[1] We do deploy the JDK separately. We have a script which takes a local path to a JDK tarball and a hostname, and installs the JDK in the right place on the target machine. This is a bit caveman, and it might be better to use something like Ansible, or make custom OS packages for specific JDKs, or even use something like asdf. But we don't need to deploy JDKs very often, so the script works for us.

[2] Although if you insist, it's pretty easy to make a self-expanding-and-running zip, so you could have a single file if you really want: https://github.com/vmware-archive/executable-dist-plugin