Better way to run installed tools on the terminal

[mbenford]

Sourcing .bingo/variables.env and running $TOOL_NAME work great on the terminal, but it's less intuitive than simply calling tool-name, as it would be if the tool were installed with go install. This could be achieved by creating a shell function named after the tool, akin to what Python's virtualenv does with deactivate:

tool() {
  ${TOOL} "$@"
}

@bwplotka I can send a PR if you think this is a valid idea.

On a slightly different note, the .env extension might lead people into thinking it's a plain dotenv file, when in fact it's a shell script. I myself tried to used it as a dotenv file with Task and it took me a few minutes to realized why it wasn't working.

[mbenford]

I kept thinking about my suggestion and although it might work and make manually running installed tools more natural, it wouldn't make it any easier to run them from other places, like a Taskfile.yml or a //go:generate directive. One solution that covers all those scenarios would be to use shims, much like many version managers do. I played with the idea a little bit on my machine by hacking some shell files and it seems to work. Here's what bingo could do when installing a tool:

1. Create a folder named shims in .bingo if it doesn't exist;
2. Create an executable script in shims called tool-name with the following content:

#!/bin/sh
GOBIN=${GOBIN:=$(go env GOBIN)}
if [ -z "$GOBIN" ]; then
	GOBIN="$(go env GOPATH)/bin"
fi
TOOL="${GOBIN}/tool-v1.0.0"
$TOOL "$@"

3. Create a script in .bingo called activate as follows:

export PATH="$PWD/.bingo/shims:$PATH"

Now one could simply run source .bingo/activate and all tools would be available in $PATH, effectively making them accessible anywhere - command line, scripts, and so on.

[mbideau]

Hi, same need here.
Using shims is a good way to mimic what's Python doing, except in Python the shims are directly installed in the .bin directory (no opinion on that).

Another user story: IDEs may want bingo run thetool
It is a common feature in other languages (see Python pipenv run, JS npm exec for example).
It would allow IDEs to run the Go tools taking advantage of the locally installed modules when editing a Go file in a project directory (when a version of the same tool might exist in the GOPATH with a different version). Especially useful for linters and formatters.
At least this is how vim-ale (a vim plugin to help linting/formatting files) is using pipenv (a Python packages manager and runner using virtual environment per project -- when PIPENV_VENV_IN_PROJECT=1). The implementation checks if there is a Pipfile.lock in the project's directory and if so, prefix all Python modules calls with pipenv run.

Maybe there is a similar way to do it for Go regarding the implementation on the IDE side: just test if there is a .bingo folder and then add the .bingo to the PATH or prefix binaries with it ...

I see two main differences with the Python/Pipenv solution :

1. the vim-ale plugin test for Pipfile.lock because dependencies for production and development are both managed in that file, when with the Go/bingo solution the go.mod file would not exists or not be a sign that bingo has been setup in that project.

2. In Go ecosystem it doesn't seem to have a recommended way to manage tooling dependencies (for now, until go get -b maybe). So it might not be relevant for IDE to start detecting .bingo folders (or whatever) until there is more consensus/adoption of the appropriate tooling.

I don't plan for implementing that in vim-ale but I could submit an issue to ask for it (limited time on my side) once that would make sens for this project.

Again, thank you for that program, that's a good way towards better Go dependency management.

[bwplotka]

Hey, thanks for feedback!

Looks like there are more and more opinions to add this (:

Here is past discussion why it was not added: #52 (comment)

All info is here: https://github.com/bwplotka/bingo#using-installed-tools

Why source .bingo/variables.env && <the tool> does not work for you cases? 🤗

[diegosz]

Hi, first many thanks for this awesome tool, been using it for a while and it's a life saver.

I completely agree with the notion of not including a run command within bingo, but I also like to keep the go:generate directives in the source code, close to the place that it belongs instead of having it far away in a makefile or some other script.

I could install the tools using the bingo get -l symlink option, but don't want any side effect by having another binary with same name or different version when jumping from one project to the other.

I've created a draft of a tool called bingorun that could be used to run the tools managed by bingo and also to install them if missing. It's just a proof of concept.

Could be used from command line or in go:generate directives, like:

//go:generate bingorun go-enum --marshal --nocase -f=$GOFILE

Just post it here, to see if it's useful for someone else with this use case.