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.
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...
So for this problem, two solutions:
- copy that file wherever we need it, thus duplicating it
- have something like
go mod path github.com/dedis/cothority/v3
that usesgo.mod
to return the correct path
If you have questions, you can contact me at linus.gasser@epfl.ch
Being able to do
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.