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: standard-library vendoring in module mode #30241

Open
bcmills opened this Issue Feb 14, 2019 · 35 comments

Comments

Projects
None yet
6 participants
@bcmills
Copy link
Member

bcmills commented Feb 14, 2019

This proposal is both a fix for #26924, and a means for users to explicitly upgrade the golang.org/x dependencies of the standard library (such as x/crypto and x/net).

Proposal

The standard library will ship with three go.mod files: src/go.mod (with module path std), src/cmd/go.mod (with module path cmd), and misc/go.mod (with module path misc).

The std and cmd modules will have vendor directories, containing modules.txt files in the usual format and managed using the standard Go 1.13 vendoring semantics (hopefully #30240).

The std and cmd modules differ somewhat from ordinary modules, in that they do not appear in the build list.

  • No module outside GOROOT/src may declare its own module path to begin with std or cmd.
  • No module may explicitly require, replace, or exclude any module whose path begins with std or cmd. (Their versions are fixed to the Go release in use.)

For files within GOROOT/src only, when we resolve an import of a package provided by an external module, we will first check the build list for that module.

  • If the build list does not contain that module, or if the version in the build list is strictly older than the one required by the standard-library module containing the file, then we will resolve the import to a directory in the standard library, and the effective import path will include the explicit prefix vendor or cmd/vendor.
    • The explicit prefix ensures that no two packages in the build will have the same import path but different source code.
    • It also ensures that any code loaded from a valid module path has a corresponding module in the build list.
  • If the version in the build list is equal to than the one required by std or cmd, that version is not replaced in the main module, and the package exists in the corresponding vendor directory, then we will load the package from vendor or cmd/vendor with its original import path.
    • This eliminates network lookups if the main module is std or cmd itself (that is, if the user is working within GOROOT/src).
    • We assume that the code in GOROOT/src/vendor and GOROOT/src/cmd/vendor will remain pristine and unmodified.
  • If the version in the build list is greater than the version required by std or cmd, or if the version is equal and the module is replaced, then we will load the package from the module cache in the usual way.
    • This may cause substantial portions of the library to be rebuilt, but will also reduce code duplication — which should result in smaller binaries.

@gopherbot gopherbot added this to the Proposal milestone Feb 14, 2019

@gopherbot gopherbot added the Proposal label Feb 14, 2019

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 14, 2019

@bcmills bcmills added the modules label Feb 14, 2019

@bcmills bcmills modified the milestones: Proposal, Go1.13 Feb 14, 2019

@bcmills bcmills changed the title proposal: standard-library vendoring in module mode proposal: cmd/go: standard-library vendoring in module mode Feb 14, 2019

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Feb 14, 2019

I am strongly in favor of using modules for vendoring in the standard library, instead of ad-hoc copies, but I don't see the reason to let applications override standard library dependencies. Was this widely requested, or something we wished we had often?

Speaking for x/crypto, I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.

Also, I don't see why we'd let users override vendored dependencies but not standard library packages. The difference between golang.org/x/crypto/chacha20poly1305 and crypto/aes should be an implementation detail of crypto/tls. Then why can one be overridden, and the other not? Feels arbitrary.

@jayconrod

This comment has been minimized.

Copy link
Contributor

jayconrod commented Feb 14, 2019

cc @ianthehat

I share some of @FiloSottile's concerns. Allowing users to override std dependencies, especially crypto dependencies, is scary. But not allowing this would be against the spirit of modules.

There are some safeguards here, but I'd love to solve this without making the module resolution and package loading logic more complicated.

Possibly dumb, low-tech idea: what if we vendor these modules without using vendoring? We could run go mod vendor, then rename the vendor directory to something else (internal/vendor_) and fix up the imports? That would fix #26924 and move complexity out of cmd/go, into tools.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 15, 2019

what if we vendor these modules without using vendoring? We could run go mod vendor, then rename the vendor directory to something else (internal/vendor_) and fix up the imports?

We have that today, in internal/x. We could fix #26924 using the same strategy in cmd, if we're ok with code duplication for the x repos. (The goal of this proposal is to reduce that duplication.)

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 15, 2019

@FiloSottile

I don't see the reason to let applications override standard library dependencies. Was this widely requested, or something we wished we had often?

It has come up at Go team summits from time to time, and while we don't see many complaints about upgrading x repos explicitly, we do see fairly frequent complaints about binary sizes (#6853 is canonical).

The two are closely related, in that one way you can end up with an overly-large binary is by pulling in a redundant copy of an x repo from the standard library.

Per my favorite quote from C. A. R. Hoare's Hints on Programming Language Design:

[L]isten carefully to what language users say they want, until you
have an understanding of what they really want. Then find some way of
achieving the latter at a small fraction of the cost of the former. This is
the test of success in language design, and of progress in programming
methodology.

It's much easier for us to reduce code duplication in the standard library than to reduce the outputs generated from duplicated code.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 15, 2019

Speaking for x/crypto, I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.

We probably should start requesting the output of go list -m all in the issue template, for precisely that reason. (The same problem can occur when someone reports an issue against x/net, and that has ~nothing to do with the standard library.)

But consider the opposite direction, too: wouldn't it be nice for folks to be able to, say, test the interaction of TLS 1.3 with their dependencies written against 'net/http`, without having to also run a bleeding-edge version of the compiler and runtime (with any associated runtime bugs)?

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 15, 2019

Also, I don't see why we'd let users override vendored dependencies but not standard library packages. The difference between golang.org/x/crypto/chacha20poly1305 and crypto/aes should be an implementation detail of crypto/tls. Then why can one be overridden, and the other not? Feels arbitrary.

That seems like a great argument for making many of the standard-library packages thin forwarding shims around x/ packages. I may file that proposal, in fact, but it's separate from this one. 🙂

@jayconrod

This comment has been minimized.

Copy link
Contributor

jayconrod commented Feb 15, 2019

I'm definitely sympathetic to reducing code duplication and binary size, but I'm also concerned about complexity and special cases.

I think we should resolve #26924 using the internal/x approach in order to unblock other module work for 1.13, and we should talk further about modularizing the standard library after 1.13. Just to confirm my understanding, converting cmd/vendor to cmd/internal/x would not significantly increase binary or SDK download size, right?

@kardianos

This comment has been minimized.

Copy link
Contributor

kardianos commented Feb 15, 2019

@bcmills @FiloSottile

We probably should start requesting the output of go list -m all in the issue template, for precisely that reason. (The same problem can occur when someone reports an issue against x/net, and that has ~nothing to do with the standard library.)

This is the same reaction I had when I saw the objection over updating the std lib versions. Make it easy and known how to list module versions and request it in issues. I also remember when Azure had to vendor a patched version of crypto/tls to access to hit their TLS endpoints in their SDK, then fork the world to make it reference the fork.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 15, 2019

@jayconrod, in looking at the details of this, it seems to be by far the simplest way to make module-mode vendoring work for vendoring in the standard library.

go mod vendor uses the import graph to figure out which packages to copy, so it's much simpler to have the module-provided packages in the import graph than to try to build some other analysis (and vendoring tool) specifically for the standard library.

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Feb 18, 2019

I don't disagree with including go list -m all in issue reports, but it still does not make me feel good about letting users swap chacha20poly1305 backends to crypto/tls. TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

@jayconrod

This comment has been minimized.

Copy link
Contributor

jayconrod commented Feb 19, 2019

@bcmills I agree that this is probably the simplest way to make module-mode vendoring work in the standard library in terms of new code that needs to be written. My concern is that this makes package loading harder to reason about. In particular, this proposal means that you may get either one or two copies of some packages, depending on what version the main module requires or whether it has a replacement. We have the same risk of conflict with exported types or global state as we do today, but now the risk is more subtle.

Here's a possible alternative (with some drawbacks at the end):

  • The Go SDK ships with go.mod files for std, cmd, and misc, as described above.
    • Imports starting with std/, cmd/, or misc/ are resolved to those modules. This will require new logic, but it would replace existing GOROOT / GOPATH package resolution.
    • These modules may have normal requirements on x/tools, x/net, etc.
  • The Go SDK ships with a pkg/mod directory, which would contain dependencies of the standard modules. It would be in the normal module cache format. It would act as a fallback read-only cache before going to the network.
  • For packages that should not be user-replaceable (i.e., chacha20poly1305), we would create private copies in internal/x. I'm hoping there wouldn't be many of these, so we could still mostly avoid code duplication in binaries.
    • I think writing a tool to do this would be fairly straightforward. Maybe this is something gorelease should do.

I'm realizing some drawbacks to this approach though, as I'm typing this out.

  • This would increase SDK size, since pkg/mod would include sources for packages we don't depend on. Not sure how much this would add.
  • Our dependencies on x/tools, x/net would effectively set global minimum versions for those modules. MVS would override user requirements on older versions.
@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 19, 2019

  • Our dependencies on x/tools, x/net would effectively set global minimum versions for those modules.

Not only that, but all of their transitive dependencies too: for example, various parts of x/net and std currently depend on x/text, and x/text has a dependency on x/tools via golang.org/x/text/cmd/gotext and golang.org/x/text/message/pipeline. x/tools has a fairly broad dependency graph (see #29981), so we would be setting minimums for a lot of arbitrary modules.

Note that everything in cmd should be a package main, so nothing can import it. That makes the cmd module a bit easier to handle than std, since it mitigates the code bloat from using a vendor directory: we know affirmatively that no binary that links against cmd will also link against a redundant x repo.

misc is similar to cmd: it does not have a globally-addressable import path, so the only time you can build anything in misc is if it's the main module.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 19, 2019

@FiloSottile

TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

I can certainly sympathize with that, but in that case, is there a fundamental reason for the implementation of crypto/tls to live in the standard library at all?

That is: if it's that tightly coupled to x/crypto, why not make it a forwarding façade over an implementation in x/crypto? That would preserve the advantages of decoupling the release cycle and reducing code bloat, while keeping the compatibility dimensions roughly equivalent to x/crypto today.

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 20, 2019

Change https://golang.org/cl/162989 mentions this issue: go/analysis: allow overriding V flag without code patches

gopherbot pushed a commit to golang/tools that referenced this issue Feb 20, 2019

go/analysis: allow overriding V flag without code patches
In CL 149609, a file was added to
src/cmd/vendor/golang.org/x/tools/go/analysis/internal/analysisflags/patch.go
to override the behavior of the V flag for cmd/vet.

That modification causes the behavior of cmd/vet to change when a
pristine copy of x/tools is vendored in, and module-mode vendoring
will only support pristine copies (see golang/go#30240).

Instead, allow cmd/vet to override the V flag by defining its own V
flag before it invokes unitchecker.Main.

Tested manually (by patching into cmd/vendor).

Updates golang/go#30240
Updates golang/go#30241
Updates golang/go#26924
Updates golang/go#30228

Change-Id: I10e4523e1f4ede94fbfc745012dadeefef48e927
Reviewed-on: https://go-review.googlesource.com/c/162989
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 20, 2019

To summarize so far: it seems that there are some concerns about the module-upgrade behavior, but no objections to the remainder of the proposal.

Since a lot of this work needs to happen early in the cycle, I'm going to go ahead and implement a more limited form: for now, we'll always resolve dependencies of the standard library to the packages in the vendor directories, and we'll only treat them as part of the external module if the working directory is within the std or cmd module proper.

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Feb 21, 2019

TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

I can certainly sympathize with that, but in that case, is there a fundamental reason for the implementation of crypto/tls to live in the standard library at all?

That is: if it's that tightly coupled to x/crypto, why not make it a forwarding façade over an implementation in x/crypto? That would preserve the advantages of decoupling the release cycle and reducing code bloat, while keeping the compatibility dimensions roughly equivalent to x/crypto today.

Making the implementation of crypto/tls swappable is interesting, and I had explored a different approach in #21753. However, I'm not sure we want to move something so core to most applications to x/crypto. For example, the security release process of x/crypto is far, far weaker.

Maybe we could still make main security releases which just bump the x/crypto dependency, but there's a lot of moving parts to this all, and I'd like to see it as a separate proposal.

(Also, I'm not convinced by the argument that a x/crypto dependency that I don't want to be a joint makes crypto/tls substantially different from any other standard library package.)

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 21, 2019

I'm not convinced by the argument that a x/crypto dependency that I don't want to be a joint makes crypto/tls substantially different from any other standard library package.

Agreed, but I think the point generalizes: any package in std that is tightly coupled to one in x could be replaced with a forwarding shim that isolates the coupling within the module.

@dmitshur

This comment has been minimized.

Copy link
Member

dmitshur commented Feb 21, 2019

I have two questions about this proposal.

The standard library will ship with three go.mod files: src/go.mod (with module path std), src/cmd/go.mod (with module path cmd), and misc/go.mod (with module path misc).

The standard library has a policy on which packages are allowed to import which others. It's codified in:

// pkgDeps defines the expected dependencies between packages in
// the Go source tree. It is a statement of policy.

Have you considered following the L0/L1/L2/L3/(L4+everything else) tiers there to guide std lib module boundaries (e.g., having stdl0, stdl1, stdl2, stdl3, stdl4 modules rather than a single std one)? Would there be benefits in doing so?

The std and cmd modules differ somewhat from ordinary modules, in that they do not appear in the build list.

What is the motivation to make these modules differ from ordinary modules?

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 21, 2019

Change https://golang.org/cl/163207 mentions this issue: misc: add go.mod file

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 22, 2019

What is the motivation to make these modules differ from ordinary modules?

std is tightly coupled to the compiler and runtime, so attempting to upgrade or replace it independent of the rest of the toolchain would be extremely error-prone.

Similarly, cmd is tightly coupled to the compiler: it's not at all clear what things like go tool vet should do if you've replaced cmd with something else.

@jayconrod

This comment has been minimized.

Copy link
Contributor

jayconrod commented Feb 22, 2019

Before proceeding with the vendoring changes, I would feel a lot better if @rsc and @ianthehat LGTM'd this proposal, and I want to make sure @FiloSottile is satisfied. What do you think about holding a feedback session?

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 22, 2019

Change https://golang.org/cl/163519 mentions this issue: cmd/go: allow "stdout" and "stderr" as inputs to script_test "cp" command

gopherbot pushed a commit that referenced this issue Feb 26, 2019

cmd/go: allow "stdout" and "stderr" as inputs to script_test "cp" com…
…mand

Updates #30241

Change-Id: I543d8914faf810835d3327baa3c84b3dff124156
Reviewed-on: https://go-review.googlesource.com/c/163519
Reviewed-by: Ian Lance Taylor <iant@golang.org>

gopherbot pushed a commit that referenced this issue Feb 27, 2019

misc: add go.mod file
Updates #30228
Updates #30241

Change-Id: I7ee839f4d2840873f7e37b3aff93fe534c6b52e6
Reviewed-on: https://go-review.googlesource.com/c/163207
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 28, 2019

Change https://golang.org/cl/164623 mentions this issue: all: move internal/x to vendor/golang.org/x and revendor using 'go mod vendor'

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 28, 2019

Change https://golang.org/cl/164618 mentions this issue: cmd: refresh cmd/vendor to match 'go mod vendor'

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 28, 2019

Change https://golang.org/cl/164619 mentions this issue: go/build: change the search order for "vendor/" paths based on srcDir

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 28, 2019

Change https://golang.org/cl/164622 mentions this issue: cmd,std: add go.mod files

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 1, 2019

Change https://golang.org/cl/164625 mentions this issue: go/internal/srcimporter: set -mod=vendor before running tests

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 1, 2019

Change https://golang.org/cl/164626 mentions this issue: cmd/go: quote expanded shell variables used within regular expressions

gopherbot pushed a commit that referenced this issue Mar 1, 2019

go/internal/srcimporter: set -mod=vendor before running tests
Otherwise, if the working directory is inside a standard-library
module, the test may try to fetch module contents from GOPROXY or
upstream.

Updates #26924
Updates #30228
Updates #30241

Change-Id: I4cb9a07721bd808fd094f7ed55a74cf7bce9cd6f
Reviewed-on: https://go-review.googlesource.com/c/164625
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 1, 2019

cmd/go: quote expanded shell variables used within regular expressions
We mostly use shell variables for paths, and we don't want file paths
like "C:\work\go1.4" to turn into regular expressions.

Updates #30228
Updates #30241

Change-Id: If18b775b2f8b2821eaf197c4be4a322066af839f
Reviewed-on: https://go-review.googlesource.com/c/164626
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 5, 2019

Change https://golang.org/cl/165377 mentions this issue: cmd/go/internal/modload: do not fetch modules in searchPackages if -mod=vendor is set

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 5, 2019

Change https://golang.org/cl/165378 mentions this issue: all: add -mod=vendor to GOFLAGS in tests that execute 'go' commands within std or cmd

gopherbot pushed a commit that referenced this issue Mar 5, 2019

cmd/go/internal/modload: do not fetch modules in searchPackages if -m…
…od=vendor is set

Updates #30228
Updates #30241

Change-Id: I6b5f842d00ba273ed241abe55a1ea71c105ec284
Reviewed-on: https://go-review.googlesource.com/c/go/+/165377
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 5, 2019

all: add -mod=vendor to GOFLAGS in tests that execute 'go' commands w…
…ithin std or cmd

Updates #30228
Updates #30240
Updates #30241

Change-Id: Idc311ba77e99909318b5b86f8ef82d4878f73e47
Reviewed-on: https://go-review.googlesource.com/c/go/+/165378
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 5, 2019

Change https://golang.org/cl/165497 mentions this issue: cmd/api: use 'go list' to locate transitive dependencies of std

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Mar 6, 2019

Change https://golang.org/cl/165749 mentions this issue: cpu: define cacheLineSize and doinit for unknown CPUs

gopherbot pushed a commit to golang/sys that referenced this issue Mar 6, 2019

cpu: define cacheLineSize and doinit for WASM
This fixes a build break when compiling this package with
GOOS=js / GOARCH=wasm.

Updates golang/go#30241

Change-Id: I0b35aa50a69370ed0d83c522e12ce7613c4c3ec4
Reviewed-on: https://go-review.googlesource.com/c/sys/+/165749
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Mar 7, 2019

We plan to make the standard-library vendor directories work in 1.13, but will defer for a later release the decision on whether (or how) to allow user modules to upgrade them.

(That is: for 1.13, the std-vendored modules, viewed from outside std, will continue to be treated as packages in the standard library and not part of the corresponding external module.)

@bcmills bcmills modified the milestones: Go1.13, Unplanned Mar 7, 2019

gopherbot pushed a commit that referenced this issue Mar 8, 2019

cmd/api: use 'go list' to locate transitive dependencies of std
With standard-library modules and vendoring, the mapping from import
path to directory within the standard library is no longer entirely
trivial. Fortunately, 'go list' makes that mapping straightforward to
compute.

Updates #30241
Updates #30228

Change-Id: Iddd77c21a527b7acdb30c17bec8b4bbd43e23756
Reviewed-on: https://go-review.googlesource.com/c/go/+/165497
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 8, 2019

go/build: change the search order for "vendor/" paths based on srcDir
If srcDir is within GOROOT, prefer GOROOT.
Otherwise, prefer GOPATH.

The attached tests may seem a bit strange; they will make more sense
in a followup CL.

Updates #16333
Updates #30241
Updates #30228

Change-Id: Ic5f1334cce5e242d7f49080aba083bcf2080dee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/164619
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 11, 2019

cmd: refresh cmd/vendor to match 'go mod vendor'
This change preserves the maximum versions from cmd/vendor/vendor.json
where feasible, but bumps the versions of x/sys (for CL 162987) and
x/tools (for CL 162989 and CL 160837) so that 'go test all' passes in
module mode when run from a working directory in src/cmd.

A small change to cmd/vet (not vendored) was necessary to preserve its
flag behavior given a pristine copy of x/tools; see CL 162989 for more
detail.

This change was generated by running 'go mod vendor' at CL 164622.
(Welcoooome to the fuuuuuture!)

Updates #30228
Updates #30241

Change-Id: I889590318dc857d4a6e20c3023d09a27128d8255
Reviewed-on: https://go-review.googlesource.com/c/go/+/164618
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 11, 2019

cmd,std: add go.mod files
Updates #30241
Updates #30228

Change-Id: Ida0fe8263bf44e0498fed2048e22283ba5716835
Reviewed-on: https://go-review.googlesource.com/c/go/+/164622
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

gopherbot pushed a commit that referenced this issue Mar 11, 2019

all: move internal/x to vendor/golang.org/x and revendor using 'go mo…
…d vendor'

This also updates the vendored-in versions of several packages: 'go
mod vendor' selects a consistent version of each module, but we had
previously vendored an ad-hoc selection of packages.

Notably, x/crypto/hkdf was previously vendored in at a much newer
commit than the rest of x/crypto. Bringing the rest of x/crypto up to
that commit introduced an import of golang.org/x/sys/cpu, which broke
the js/wasm build, requiring an upgrade of x/sys to pick up CL 165749.

Updates #30228
Updates #30241
Updates #25822

Change-Id: I5b3dbc232b7e6a048a158cbd8d36137af1efb711
Reviewed-on: https://go-review.googlesource.com/c/go/+/164623
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.