You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
package main
import"fmt"funcmain() {
fmt.Println("hello world")
}
If we use go mod vendor for it, it can't guarantee the code of fmt is consistent.
Pros:
It will help people to track the changes on stdlib, such as unexpected changes on stdlib when they upgrade Go version.
Make debugging stdlib on the fly much easier. Such as people may modify the source code of fmt in their local GOROOT and forget to revert it. If the vendor has a copy of fmt, it will be much easier to modify the stdlib.
Make cross-compile stdlib between different Go runtime much easier. Such as let old stdlib benefit from the improvements from newer GC, etc.
Cons:
May break things if the newer Go compiler tries to compile old stdlib?
Hard to implement? The development cost can't justify the gain.
Maybe we can first add a flag to the CLI to make it optional: go mod vendor -s, s means also include the stdlib.
The text was updated successfully, but these errors were encountered:
The standard library — particularly the runtime package — is tightly coupled to the Go compiler. It is infeasible to vendor the standard library separately from the compiler.
Certain parts of the standard library could be made into wrappers around external modules, and in theory we could then allow those modules to be upgraded and vendored separately from the standard library. That proposal is #30241.
For example, the source code like below:
If we use
go mod vendor
for it, it can't guarantee the code offmt
is consistent.Pros:
fmt
in their localGOROOT
and forget to revert it. If the vendor has a copy offmt
, it will be much easier to modify the stdlib.Cons:
Maybe we can first add a flag to the CLI to make it optional:
go mod vendor -s
,s
means also include thestdlib
.The text was updated successfully, but these errors were encountered: