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

proposal: Go 2: No more goroot, everything into gopath #29070

Closed
gertcuykens opened this issue Dec 3, 2018 · 8 comments
Closed

proposal: Go 2: No more goroot, everything into gopath #29070

gertcuykens opened this issue Dec 3, 2018 · 8 comments

Comments

@gertcuykens
Copy link
Contributor

gertcuykens commented Dec 3, 2018

On install go get -u stdlib to download the stdlib into gopath. No more goroot chenanigans especially for IDE's

Sam told me there was already a proposel in the making when stdlib are transfert into modules to do so, but I can't find that proposel so I made a new one sorry.

https://groups.google.com/forum/#!topic/golang-nuts/nN50r9qg9UI

@gopherbot gopherbot added this to the Proposal milestone Dec 3, 2018
@ianlancetaylor
Copy link
Contributor

Note that the modules work is going to essentially eliminate GOPATH.

@gertcuykens
Copy link
Contributor Author

gertcuykens commented Dec 3, 2018

Yes and no if I am not mistaken the cached modules get stored in gopath right? Esentially the vendor map get replaced into a gopath? A gopath is still required but just hidden. Also for installing bin's using go install we need a gopath. The goroot we can get completely rid off in my view and totally unnecessary once the stdlib are modules too.

@bcmills
Copy link
Contributor

bcmills commented Dec 3, 2018

Yes and no if I am not mistaken the cached modules get stored in gopath right?

They're cached to GOPATH/pkg, not GOPATH/src, and the layout is one directory per module (that is, per path+version combined) rather than a unified package tree.

@bcmills
Copy link
Contributor

bcmills commented Dec 3, 2018

Also for installing bin's using go install we need a gopath.

Not as of 1.12. (#24250 is fixed at head.)

@bcmills
Copy link
Contributor

bcmills commented Dec 3, 2018

The goroot we can get completely rid off in my view and totally unnecessary once the stdlib are modules too.

The defining characteristic of a module is that it participates in version selection. The standard library, on the other hand, is tightly coupled to the runtime and compiler: you almost certainly cannot use a Go 1.14 version of the runtime/debug with a Go 1.13 compiler and runtime (or vice-versa).

We can probably move parts of the standard library out into modules, but there will always be some core whose version is pinned to the toolchain.

@bcmills bcmills added the GoCommand cmd/go label Dec 3, 2018
@gertcuykens
Copy link
Contributor Author

gertcuykens commented Dec 3, 2018

I was hoping that for does runtime parts the module specification could be adapted that not only for Go 1.13 / Go 1.14 but also when we are mixing Go 1 and Go 2 we can have multiple runtime parts in does scenario's. The module system check's go version and figure out which runtime part is needed. Older and current realeas use goroot but future release switch to runtime modules that can mix Go 1 and Go 2 runtime parts.

@ianlancetaylor
Copy link
Contributor

@gertcuykens I want to be clear that what you describe is extremely difficult to accomplish and it is not a goal. For a clearer expression of the goal please see #28221 and the proposal document that it links to.

@gertcuykens
Copy link
Contributor Author

gertcuykens commented Dec 3, 2018

I learned in life when the person who wrote the thing is saying that it's extremely difficult to accomplish, it's usually even more complecated then that :) The goal you linked is clear. But I do hope everybody tries his or her best to reach a absolute minimal goroot as a goal. Thx for response closing this in favor of #28221

os/signal
plugin
reflect
runtime
runtime/cgo
runtime/debug
runtime/msan
runtime/pprof
runtime/race
runtime/tsan
sync
sync/atomic
testing
time
unsafe

@golang golang locked and limited conversation to collaborators Dec 3, 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