I am currently migrating from GOPATH to go.mod. However, I cannot understand this:
I read everywhere that
GOPATHandgo.moddoes not mix, either this or thatbut then the go modules use
GOPATHto download requirements...
So, the go modules approach uses GOPATH, which it claims to replace...
As I try to wrap my head around what is going on, my understanding is this:
GOPATH was originally a way to manage user projects AND dependencies. The user projects are now managed by the go module system, but the other functionality, the external/remote dependencies are still under GOPATH jurisdiction. GOPATH essentially became what a virtual env is in python, a library-dump.
Consequently, the go directory structure is something like this:
$HOME/
$HOME/programming
$HOME/programming/go
$HOME/programming/go/deps <- GOPATH points here
$HOME/programming/go/module1
$HOME/programming/go/module2
By setting GOPATH to different dirs in the build script, I could have different compile environments. However, as far as I understand, this is not needed, as go modules can handle if different projects in the same module require different versions of the same dependency.
$HOME/programming/go/deps1
$HOME/programming/go/deps1/some_lib.1.1
$HOME/programming/go/deps2
$HOME/programming/go/deps1/some_lib.2.2
Questions:
If GOPATH is the past since 1.11, why is it still fundamental at 1.19?
Is my approach to answer the above question correct, or do I misunderstand something?
I set my GOPATH to ~/gp
And everytime some import statements needs a package, it will end up there. In example above I just hit a[tab] to show a small section of all the stuff in that directory, there is a lot.
When inside a directory with a go.mod file I run:
The
tidycommand it great! It will download what is missing or use what you got.