[FR] Have portable, statically-linked releases for Linux

[NightMachinery]

Looking at the install options, there is no easy way to install a PCRE-capable ugrep on a Linux machine without having root access. (It's possible using Homebrew, but it's very slow as it builds everything from source if you are non-root.)

It'd be great if there were portable, statically linked binaries that could be installed with a simple:

curl -LsSf https://... | sh

PS: ripgrep can be installed this way:

curl -sS https://webi.sh/rg | sh

I actually noticed this problem because I recently changed my main grep tool from rg to ugrep in emacs, and I didn't have ugrep installed on my university servers.

[genivia-inc]

I agree. If I only knew how to do this. I hope a Linux expert is interested in this who can help?

One way to install ugrep locally is to download the repo zip and execute ./build.sh, but it does not load and install the dependencies for you.

[leahneukirchen]

One could build a Dockerfile that makes a static build using Alpine or so? And run this from GitHub actions?

[genivia-inc]

Static binaries are included in release 6.1 in the bin directory.

However, I still need to write a script to pipe to sh with curl or wget to fetch the static release builds to locally install or copy.

[stdedos]

Releasing artifacts inside a git-repo is an anti-pattern that keeps generating work for (active) package maintainers - but I guess that fight was lost long ago.

Please don't continue down the anti-pattern road and introduce curl | sh stuff 😕 (https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install, https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ - sadly certificate is outdated, but still page is original)

Since you don't want to go down the Github Releases road, maybe introduce a latest tag that you keep force-pushing forward?

Then https://github.com/Genivia/ugrep/tree/latest/bin will always be the latest release (similar to how https://github.com/Genivia/ugrep/tree/v6.1.0/bin works)

[genivia-inc]

Yes, I'm conflicted about this too. I'm not sure I will continue including Linux amd64 and arm64 in the bin directory in the future.

It is also extra manual labor to do the builds in Linux containers, so I'd be glad not to have to do that.

[stdedos]

You don't have to do much. Just generate a CI action to do it for you (yeah, I realize that that is "a lot of work").

I know that for "personal fun consumption stuff" it's maybe not worth it, but then when a thing works, it works. And it can be perfectly replicatable "for ever", and update it at your speed (and/or via dependabot)

[genivia-inc]

By "work" I mean having to deal with more moving parts that can break and/or complicate maintenance. CI actions are great for standard stuff. In the long run stuff will change or transition and then you'll have to go back and remember everything about how it was set up to set up again, possibly differently. It happened to me a few times.

This isn't the only project I work on. The less stuff I have to worry about that can break, the better.

[genivia-inc]

@fasterit do you have any thoughts on using this to point to the autobuild-static artifacts?

https://nightly.link

I tried it out and works fine to get a link to the artifacts by pasting the URL https://github.com/Genivia/ugrep/blob/master/.github/workflows/autobuild-static.yml

Could install this app in the ugrep repo perhaps.

[fasterit]

Yes, it works fine and may be the static builds are useful for people that either want the latest and greatest or are hunting for bugs. Do note that the maximum retention of these build artifacts on Github is 90 days. Your committed builds (under /bin/linux_*) are - of course - not affected by that. So you probably want to advertise both and explain the difference between release and commit-builds.

Please do install the app so you cannot be hit by the Github API limits easily that are otherwise shared by all the nightly.link website users.

/DLange