Request: prebuilt binaries released on github

[somename123]

First of all thank you for your work in this project, such a usefull thing to use with ranger.

I already read that you wrote:

TBH, personally I don't have any motive to create packages of Pistol for any distro, not even my own (NixOS). As a developer of this program, I just install it to $GOPATH/bin/ and this is how I continuously test it while changing it.

But have you thought how usefull ranger and pistol are on tiny less powerfull computers , SBC boards etc, on ARM architecture. ?
Think of Raspberrry Pi and alike. It's not practical, for non developers/programmers to constantly download and redownload again and again the entire Go chain infrastructure and build on them constantly.

It also eases the work of distro package maintainers, who want to provide an easy to install package. Example, in AUR, Archlinux, in addition to a package called "pistol-git" that already exists, one could provide and additinial "pistol-bin" package, that just pulls from the github repo the released bin. That's how so many Go projects are package in Archlinux do it.

I also know it can be cumbersome to support "all" of arm architectures . But usually all it takes is one single arm for 32 bit that runs on all arm5, 6, 7 and and another for arm64. Go projects 99% of the time run wonderfully on all them.

So many other (go) projects do this. Are you aware of github actions/workflows, goreleaser etc. and all the no cost ways to automate this ?

See one of many examples, https://github.com/tsl0922/ttyd/tree/master/.github

Or even lf , with so many different plattforms, https://github.com/gokcehan/lf/releases that uses travis,
https://github.com/gokcehan/lf/blob/master/.travis.yml
No end user would even want to try lf instead of ranger on a raspberry pi, if you had to download 500 mega of go just to compile it.

It's really a pitty missing this and the real power of Go being such an universal and easy to distribute to different architectures.

Thanks in advance

[Doron Behar]

I already read that you wrote:

I should update that README, see #23 .

The issue with pistol, that Lf doesn't have, is that Pistol needs libmagic installed (README explains it). Since every other distro install it potentially differently, I can't rely on that. Moreover, my beloved distro (NixOS) is unique in this sense, and that makes me unable to produce locally binaries that would run on other more common distros. Now that Pistol is somewhat stable, I do rely on my distro's package, since the executable is linked to the libmagic library installed by Nix, my package manager. You probably don't understand right now the complicity, but I can't explain it fully since you need to understand how Nix works for that.

So many other (go) projects do this. Are you aware of github actions/workflows, goreleaser etc. and all the no cost ways to automate this ?

Ideally, I would like to do that all via Nix. Note that the challenge is to get a static build of libmagic, and that'd probably need musl. Then, get this build for all platforms, and then we'll be able to do something with go.

No end user would even want to try lf instead of ranger on a raspberry pi, if you had to download 500 mega of go just to compile it.

I know, and you are right. I also appreciate your desire for this project, and your apparent frustration out of this obstacle, but consider this: NixOS is awesome because we have a lot of packages, and our repo is the most updated compared to other distros. We include Lf and Pistol, and so NixOS users don't complain :).

I don't see your request as something that will improve packagers' experience, as I think package manager should compile packages by themselves, no matter if upstream (me) provides prebuilt executables.

However, indeed it'd be nice for users of common bad distros to wget lf and pistol when they use some arm machine. Static compilation shouldn't necessary happen via Nix, I'm just a fan. If you'd like to contribute, and perhaps setup a GitHub / GitLab CI that will build pistol statically on your fork, I'd be more then happy to merge your work :).

[Doron Behar]

I'll close this issue in favor of #23 once the README will be updated.