install-or-upgrade-comby.sh should use brew on mac instead of modifying /usr/local/bin

[felixfbecker]

No description provided.

[rvantonder]

brew takes at least a couple of hours to update for any release, sometimes longer (days). We can do this, but be aware that for blocking issues that need a recent version of comby not yet on brew will then have to wait for brew, or install it manually. I'd like buy-in from the @sourcegraph/automation team if we do this.

[eseliger]

In my opinion brew really is a PITA when it comes to managing versions well for using an older version when you checkout an older commit for example, so it feels much more manageable to either download it from GitHub directly or otherwise try to use docker to keep it even local to the project root (somehow) 🤔

[rvantonder]

As far as Docker goes: I don't see an easy/obvious way to go about it because the Go binaries that call out to comby expect it on the PATH, and we don't run these Go binaries inside a Docker container for dev.

[felixfbecker]

In my opinion brew really is a PITA when it comes to managing versions well for using an older version when you checkout an older commit for example, so it feels much more manageable to either download it from GitHub directly or otherwise try to use docker to keep it even local to the project root (somehow)

Still better to manage versions than to write to global system folders from the script, no?

I would expect changes in comby to generally be backwards-compatible (at least I don't see a reason why comby would break the arguments interface) so you wouldn't have to install an older version when checking out an older commit. Running with the latest should be fine.

[mrnugget]

I personally don't think it's an issue.

Could a compromise be that it's downloaded into the $SOURCEGRAPH_REPO/.bin folder and devs have to setup their $PATH (using .envrc/.env, for example) to include that?

[rvantonder]

I'd like to push for a self-managed install, as per #6902.

Could a compromise be that it's downloaded into the $SOURCEGRAPH_REPO/.bin folder and devs have to setup their $PATH (using .envrc/.env, for example) to include that?

I think this is a great solution to self-manage. If there is a consensus on that sort of thing for development, we could document it in local_development.md. Other than that, I wouldn't like to enforce this or maintain the scripts behind it. For example, @mrnugget suggestion could also apply to golang-migrate which is a self-managed install for Ubuntu in the docs:

# install golang-migrate (you must move the extracted binary into your $PATH)
curl -L https://github.com/golang-migrate/migrate/releases/download/v4.7.0/migrate.linux-amd64.tar.gz | tar xvz

[ryan-blunden]

The Yarn installation script (performs upgrades too) is really neat and also takes care of adding the required code to your .bash_profile file.

curl --compressed -o- -L https://yarnpkg.com/install.sh | bash

[rvantonder]

Noted, thanks @ryan-blunden. I think anyone is welcome to use that solution as another option. I'm closing this now, because going forward this is self-managed.

[ggilmore]

@rvantonder

Why not write an asdf plugin for comby: https://asdf-vm.com/#/plugins-create ? We're going to use this to manage our Go/Node versions.

[rvantonder]

I'll look into it @ggilmore, thanks.

[mrnugget]

I also use asdf locally to manage Go/OCaml/Nodejs/Ruby versions, would be cool to see Comby use that 😄