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

[gertcuykens]

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

[ianlancetaylor]

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

[gertcuykens]

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]

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]

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

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

[bcmills]

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.

[gertcuykens]

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]

@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]

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