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

Don’t depreciate GOPATH #47376

Closed
markbesley opened this issue Jul 24, 2021 · 1 comment
Closed

Don’t depreciate GOPATH #47376

markbesley opened this issue Jul 24, 2021 · 1 comment

Comments

@markbesley
Copy link

What version of Go are you using (go version)?

$ go version
Version go1.16.6 Darwin/amd64

Does this issue reproduce with the latest release?

This issue is threatened for the next issue.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=“off”
GOPATH=“~/go”

What did you do?

What did you expect to see?

The Go package system was fundamental to the ease an elegance of the go programming language development experience. Please don’t destroy it. With it we can mirror local and remote packages. All the information is in the source files. No extra configuration files required. These are all well documented design decisions that made Go a wonderfully elegant programming experience.

Source versioning could be managed purely with subdirectory naming conventions.

The Module system as implemented now is too complex and broken and suggests the the 3 original designers were not involved with its design, or their views were not given enough weight. I would suggest you discuss this with those 3 designers.

At the moment local Modules cannot be easily imported without manually writing their path in the go.mod file. This contradicts the original design element of no configuration files. This is a poor decision and suggests it’s design was not thought out throughly.

By being able to uses GOPATH we are able to mirror local and remote packages. With out it we have manually edit every go.mod file to reflect the location of every local package we use. If this statement is incorrect then it still reflects the complexity introduced to the Go programming environment with Modules, something the 3 designers went to a lot of trouble to eliminate.

Complexity is introduced when the problem is not well understood. Rob Pike stated this when he says “simplicity is hard”. I suggest the Module system could be redesigned to remove this unnecessary complexity.

In the mean time keep the original GOPATH design and don’t depreciate it. It’s elegant and simple, key design features that make Go the wonderful language that it is.

What did you see instead?

@seankhliao
Copy link
Member

Duplicate of #37755

@seankhliao seankhliao marked this as a duplicate of #37755 Jul 24, 2021
@golang golang locked and limited conversation to collaborators Jul 24, 2022
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

3 participants