Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nnnn20430 opened this issue Sep 25, 2018 · 5 comments
Closed

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

nnnn20430 opened this issue Sep 25, 2018 · 5 comments

Comments

@nnnn20430
Copy link

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...

@nnnn20430 nnnn20430 changed the title cmd/go: why depricate GOPATH just to add versioning? cmd/go: why deprecate GOPATH just to add versioning? Sep 25, 2018
@bcmills
Copy link
Contributor

bcmills commented Sep 25, 2018

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
Copy link
Contributor

bcmills commented Sep 25, 2018

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.

@bcmills bcmills closed this as completed Sep 25, 2018
@ianlancetaylor
Copy link
Contributor

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

@nnnn20430
Copy link
Author

nnnn20430 commented Sep 25, 2018

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
Copy link
Author

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

@golang golang locked and limited conversation to collaborators Sep 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants