| Age | Commit message (Collapse) | Author |
|---|
|
package paths in 'go mod vendor'
copyMetadata walk-up to parent directory until the pkg become modPath.
But pkg should be slash-separated paths. It have to use path.Dir instead of
filepath.Dir.
Updates #46867
Fixes #47014
Change-Id: I44cf1429fe52379a7415b94cc30ae3275cc430e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/330149
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 835d86a17ebf32a3cb081f66119c74363dbd8825)
Reviewed-on: https://go-review.googlesource.com/c/go/+/332330
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Carlos Amedee <carlos@golang.org>
|
|
tidy and vendor
'go mod tidy' and 'go mod vendor' normally report errors when a
package can't be imported, even if the import appears in a file that
wouldn't be compiled by the current version of Go. These errors are
common for packages introduced in higher versions of Go, like "embed"
in 1.16.
This change causes 'go mod tidy' and 'go mod vendor' to ignore
missing package errors if the import path appears to come from the
standard library because it lacks a dot in the first path element.
NOTE: This change is not a clean cherry-pick of CL 298749 because
parts of modload were substantially rewritten after 1.15.
Fixes #44792
Updates #27063
Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/298749
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 56d52e661114be60fb1893b034ac0c5976b622af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298950
|
|
`go mod vendor` should create vendor/modules.txt even when the only deps
in go.mod are unused.
Fixes: #36580
Change-Id: I92a746d3f013bc2bdc3d2cec6e14b16f606c2edd
GitHub-Last-Rev: ea39a1c62294f42e5e5aab049f466189de0fd42d
GitHub-Pull-Request: golang/go#36920
Reviewed-on: https://go-review.googlesource.com/c/go/+/217135
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This change deletes several internal packages, replaces imports to
them with the equivalent golang.org/x/mod packages, updates x/mod, and
re-runs 'go mod vendor'.
Packages are replaced as follows:
cmd/go/internal/modfile → golang.org/x/mod/modfile
cmd/go/internal/module → golang.org/x/mod/module
cmd/go/internal/semver → golang.org/x/mod/semver
cmd/go/internal/sumdb → golang.org/x/mod/sumdb
cmd/go/internal/dirhash → golang.org/x/mod/sumdb/dirhash
cmd/go/internal/note → golang.org/x/mod/sumdb/note
cmd/go/internal/tlog → golang.org/x/mod/sumdb/tlog
Updates #31761
Fixes #34924
Change-Id: Ie3bf677bb0be49af969f654a0214243a6547eb57
Reviewed-on: https://go-review.googlesource.com/c/go/+/202698
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
The -modcacherw flag is now registered in work.AddModCommonFlags,
which is called from work.AddBuildFlags, where it was registered
before. 'go mod' subcommands register the flag by calling
work.AddModCommonFlags directly.
Also, build commands now exit with an error if -modcacherw is set
explicitly (not in GOFLAGS) in GOPATH mode.
Updates #31481
Change-Id: I461e59a51ed31b006fff4d5c57c2a866be0bbf38
Reviewed-on: https://go-review.googlesource.com/c/go/+/202563
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
or lower
Updates #33848
Change-Id: I887d78179d467030f4177d1834ccefee28a55c8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/201257
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
This implements the proposal described in
https://golang.org/issue/33848#issuecomment-537222782.
Fixes #33848
Change-Id: Ia34d6500ca396b6aa644b920233716c6b83ef729
Reviewed-on: https://go-review.googlesource.com/c/go/+/198319
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
In module mode, 'go get' should not consider build constraints when
loading packages in order to modify the module graph. With this
change, 'go get' considers all build tags to be true except for
"ignore" and malformed build constraint expressions.
When 'go get' builds packages, it still applies build constraints for
the target platform.
Fixes #32345
Change-Id: I6dceae6f10a5185870537de730b36292271ad124
Reviewed-on: https://go-review.googlesource.com/c/go/+/179898
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Right now they are in a deterministic order
but one that depends on the shape of the import graph.
Sort them instead.
Change-Id: Ia0c076a0d6677a511e52acf01f38353e9895dec2
Reviewed-on: https://go-review.googlesource.com/c/go/+/174527
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
vendor'
'go mod vendor' already drops test files and testdata directories, so
users should not expect the vendored module to include unnecessary
files in general.
Files tagged "ignore" are typically only used to refresh or regenerate
source files within the module to be vendored, so users of that module
do not need them.
Fixes #31088
Change-Id: I1ce9545e9b37c8e779a1826a9d494ac29d2cbfb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/172978
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This is as minimal a change as I could comfortably make to enable 'go
get' outside of a module for 1.12.
In general, commands invoked in module mode while outside of a module
operate as though they are in a module with an initially-empty go.mod
file. ('go env GOMOD' reports os.DevNull.)
Commands that operate on the current directory (such as 'go list' and
'go get -u' without arguments) fail: without a module definition, we
don't know the package path. Likewise, commands whose sole purpose is
to write files within the main module (such as 'go mod edit' and 'go
mod vendor') fail, since we don't know where to write their output.
Since the go.sum file for the main module is authoritative, we do not
check go.sum files when operating outside of a module. I plan to
revisit that when the tree opens for 1.13.
We may also want to revisit the behavior of 'go list': it would be
useful to be able to query individual packages (and dependencies of
those packages) within versioned modules, but today we only allow
versioned paths in conjunction with the '-m' flag.
Fixes #24250
RELNOTE=yes
Change-Id: I028c323ddea27693a92ad0aa4a6a55d5e3f43f2c
Reviewed-on: https://go-review.googlesource.com/c/148517
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
`go vendor` is now `go mod vendor`. So it should be unified to use `go mod vendor` in error messages.
Change-Id: I9e84b9a4f4500659b183b83040867b12a8d174aa
GitHub-Last-Rev: 8516e246d4e7f70bf21311b4cb8cb571a561815b
GitHub-Pull-Request: golang/go#28347
Reviewed-on: https://go-review.googlesource.com/c/144379
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The current "go mod" command does too many things.
The design is unclear.
It looks like "everything you might want to do with modules"
which causes people to think all module operations go through
"go mod", which is the opposite of the seamless integration we're
going for. In particular too many people think "go mod -require"
and "go get" are the same.
It does make sense to put the module-specific functionality
under "go mod", but not as flags. Instead, split "go mod" into
multiple subcommands:
go mod edit # old go mod -require ...
go mod fix # old go mod -fix
go mod graph # old go mod -graph
go mod init # old go mod -init
go mod tidy # old go mod -sync
go mod vendor # old go mod -vendor
go mod verify # old go mod -verify
Splitting out the individual commands makes both the docs
and the implementations dramatically easier to read.
It simplifies the command lines
(go mod -init -module m is now 'go mod init m')
and allows command-specific flags.
We've avoided subcommands in the go command to date, and we
should continue to avoid adding them unless it really makes
the experience significantly better. In this case, it does.
Creating subcommands required some changes in the core
command-parsing and help logic to generalize from one
level to multiple levels.
As part of having "go mod init" be a separate command,
this CL changes the failure behavior during module initialization
to be delayed until modules are actually needed.
Initialization can still happen early, but the base.Fatalf
is delayed until something needs to use modules.
This fixes a bunch of commands like 'go env' that were
unhelpfully failing with GO111MODULE=on when not in a
module directory.
Fixes #26432.
Fixes #26581.
Fixes #26596.
Fixes #26639.
Change-Id: I868db0babe8c288e8af684b29d4a5ae4825d6407
Reviewed-on: https://go-review.googlesource.com/126655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This CL corresponds to CL 123361, the final manual CL in that repo,
making this the final manual sync.
All future commits will happen in this repo (the main Go repo),
and we'll update x/vgo automatically with a fixed patch+script.
Change-Id: I572243309c1809727604fd704705a23c30e85d1a
Reviewed-on: https://go-review.googlesource.com/123576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
