Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

After getting used to GOPATH

When first encountering Golang, usage of GOPATH was really hard: why should everything be in the same directory structure? What about versioning? How can I stop making it break?

Using gopkg.in was a very good band-aid that worked very well for 3 years. Over time we got used to the GOPATH, even when it disappeared into go env GOPATH. We got so used to it, that we started using it in bash scripts, like this:

. $( go env GOPATH)/src/github.com/dedis/cothority/libtests.sh

Which is very nice, because now you can use this bash-script in all other repositories, too. And as long as your repository depends on github.com/dedis/cothority, you get the bash-script, too.

Enters go modules

Using go modules, and the GO111MODULE=on, things still worked on my computer, but not on somebody else's computer. Because (s)he had the github.com/dedis/cothority repository somewhere hidden under a special name, so because (s)he never had checked it out in his GOPATH, it was not available.

Which means, that the above line now becomes something like this:

LIBTEST=$( go env GOPATH)/src/github.com/dedis/cothority/libtests.sh
if [ ! -x "$LIBTEST" ]; then
  GO111MODULE=off go get github.com/dedis/cothority
fi
. "$LIBTEST"

Theoretically, we could write something like:

. $( go env GOPATH)/pkg/mod/github.com/dedis/cothority/v3@v3.0.0-pre1/libtests.sh

But if I remember correctly, go mod wants to change that path in a future version...

Possible solution

So for this problem, two solutions:

  1. copy that file wherever we need it, thus duplicating it
  2. have something like go mod path github.com/dedis/cothority/v3 that uses go.mod to return the correct path

Contact

If you have questions, you can contact me at linus.gasser@epfl.ch

@variadico

This comment has been minimized.

Copy link

commented Jun 6, 2019

Being able to do

. $( go env GOPATH)/src/github.com/dedis/cothority/libtests.sh

is really nice and useful, especially in a big codebase, where people write more and more utility scripts.

At every job I've had, we've always ended up standardizing on some path anyway, usually, $HOME/company. I'm really bummed this might not be here anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.