-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Have portable, statically-linked releases for Linux #373
Comments
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 |
One could build a Dockerfile that makes a static build using Alpine or so? And run this from GitHub actions? |
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. |
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 Since you don't want to go down the Github Releases road, maybe introduce a 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) |
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. |
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. |
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. |
@fasterit do you have any thoughts on using this to point to the autobuild-static artifacts? 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. |
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 |
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:
PS:
ripgrep
can be installed this way: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.
The text was updated successfully, but these errors were encountered: