Quote:
Originally Posted by PJo336
People explicitly do NOT have go, so I need to stick to binary. My plan was a install.sh that runs a curl and puts it into usr/local/bin so its on your path already (i dont know if that's considered intrusive).
What I tend to do is something like
bash -c "$(curl https://path/to/some/script.sh)"
where the script does the install. "How" is of minor important - the nice thing about doing it this way is that you can change your mind in the future.
Are all the consumers on the same OS? Then what I'd do is make an apt or rpm package as appropriate, probably. There are good tools for this, like "fpm" which can make either apt or deb packages from a tarfile or directory on disk, etc. There are tools which set up repos for you, I use a tool that sets up an RPM and APT repo on s3.
So my shell script basically sets up the users computer to access my repo, installs the package, then does anything else it needs to do (in my case it creates some custom config files and some cleanup)
This is overkill if you're talking about just a few people. I think I'd still do the website-that-has-a-bash-script route, but I'd have it just download the binary and put it in the right place. /usr/local/bin/ is OK. This is not optimal but it's not the end of the world.
Another thing I have done is distribute the tool as a docker repo, and people run it like
docker run myrepo/myimage:latest
this is fine if everyone already uses docker for everything (we do) and your program can run under the restrictions docker imposes. It has the advantage of mostly working regardless of the users' OS (mac, linux and depending on the program, windows too)