ineiti/CothorityModules.md

## CothorityModules.md

      
    Raw
  

              CothorityModules.md
            
          
    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:

copy that file wherever we need it, thus duplicating it
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