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: cmd/go: make "go mod vendor" also copied the used std libs #45612

Closed
ysmood opened this issue Apr 17, 2021 · 2 comments
Closed

proposal: cmd/go: make "go mod vendor" also copied the used std libs #45612

ysmood opened this issue Apr 17, 2021 · 2 comments

Comments

@ysmood
Copy link

ysmood commented Apr 17, 2021

For example, the source code like below:

package main

import "fmt"

func main() {
    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.

@gopherbot gopherbot added this to the Proposal milestone Apr 17, 2021
@bcmills
Copy link
Contributor

bcmills commented Apr 21, 2021

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.

@ysmood
Copy link
Author

ysmood commented Apr 21, 2021

Thanks for the mention!

@ysmood ysmood closed this as completed Apr 21, 2021
@golang golang locked and limited conversation to collaborators Apr 21, 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