cmd/go: why deprecate GOPATH just to add versioning?

[nnnn20430]

I really dislike the new module system, especially when running with GO111MODULE=on where GOPATH and the concept of workspaces are completely abandoned. With it, the only real way to import an external package is with a url, which makes additional network requests. Even the build command has to do them... (I don't want the build command doing network requests!)
I also don't like how it creates a zip cache for every version, this seems very wasteful. and unfriendly for quick hacks...

If adding versioning to achieve reproducible builds is desired, why not simply tweak the normal go build command just a little to make it try to find a file such as go.mod, where that file specifies the version it needs just like the require statement does at the moment, but instead of doing network requests, make it just try to find the checked-out git repo in GOPATH (like it normally would), find a matching version tag and then checkout a copy of the repo inside the /tmp/go-build* working dir and use that to build?

Can someone explain why the current module system doesn't use the already cloned git repos in GOPATH?
Why does the entire importing process need to change?

I personally really like workspaces in go and I don't want them to go away. They're a nice place to store my go code, act as a repository for all the dependencies that I can quickly look at, and also hack (because they are in a predictable and intuitive path and not in damn zip files) without the need to checkout the repo again. They act as the root for all the import paths in a consistent, predictable and intuitive way without the need to make damn config files!

Also, I know that if I want to import an external package without fetching from a server I can use the replace statement in go.mod but why do I have to write a config file just to do that? What happend to convention over configuration?
And how can I control when it gets updated easily? I want to be able to run go get -u for it to quickly pull the latest commits, and still use the checked-out dir in GOPATH to also use my modifications instead of stupid zip files!

There is no need to reinvent the wheel or fix what isn't broken. If the importing system needs to be extended, extend it, use a new file, but just have it alter the behavior of the build command to checkout copies of repos from the workspace, please don't change the way the import path is resolved...

[bcmills]

I don't want the build command doing network requests!

It only makes network requests for modules that are not already in the local cache.
You can disable network fetching explicitly by setting GOPROXY=off.

unfriendly for quick hacks...

See https://github.com/rogpeppe/gohack.

Can someone explain why the current module system doesn't use the already cloned git repos in GOPATH?

See https://research.swtch.com/vgo-why-versions.

Why does the entire importing process need to change?

If it allows arbitrary local edits within GOPATH, then the build is no longer reproducible. If it does not allow arbitrary edits within GOPATH, then it's difficult to make independent edits to otherwise-unrelated modules.

I personally really like workspaces in go and I don't want them to go away.

See also #27542. And we're likely to make some improvements to vendor/ support in module mode, too.

without the need to make damn config files!

Most go interactions should not require explicit edits to go.mod. If you just use go build and go test as usual, they'll update the module definition as needed.

[bcmills]

There doesn't seem to be anything actionable here. #24301 was filed back in early March and accepted in May. The overall design is set at this point.

[ianlancetaylor]

The right place for this kind of discussion is the golang-dev@googlegroups.com mailing list.

[nnnn20430]

None of my points were really addressed, i already read everything that was referenced and am not satisfied, i will attempt to write to the mailing list tomorrow as I'm too tired right now.

[nnnn20430]

It's taking far longer than I anticipated to write this, so maybe not today.