| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I31689dc8de1f6b95bb35578b20533c63903f7258
GitHub-Last-Rev: 5bfee0535ded703f84d45390d5a87295b6e5fe5a
GitHub-Pull-Request: golang/go#47418
Reviewed-on: https://go-review.googlesource.com/c/go/+/337691
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Russ Cox <rsc@golang.org>
|
|
Module-related help pages now contain a brief summary and point to the
reference documentation at golang.org/ref/mod for details.
Help pages for commands like 'go get' still describe the basic usage
and summarize flags but don't provide as much background detail.
Fixes #41427
Fixes #43419
Change-Id: Icacd38e0f33c352c447cc5a496c99674493abde2
Reviewed-on: https://go-review.googlesource.com/c/go/+/282615
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
'go help mod init' now mentions that the module path can be derived
from the directory within GOPATH. We no longer mention version
control, since that's now ignored.
Fixes #36775
Change-Id: Ia5559ecb537fccd838eeab84517e76aa01989292
Reviewed-on: https://go-review.googlesource.com/c/go/+/261539
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
InitMod is split into two functions. LoadModFile parses an existing
go.mod file and loads the build list (or checks vendor/modules.txt for
consistency in vendor mode). CreateModFile creates a new go.mod file,
possibly inferring the module path and importing a vendor
configuration file.
Some logic is moved from runInit to CreateModFile. init-specific logic
is removed from other functions.
This CL shouldn't cause substantial differences in behavior, though
some error messages are slightly different.
For #41712
Change-Id: Ia684945cfcf5beca30bbb81e7144fc246c4f27ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/264621
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This makes error reporting a bit more consistent for 'go mod'
subcommands. Most of these commands only work in module mode when a
go.mod file is present.
Setting modload.ForceUseModules reports an error when GO111MODULE=off.
Setting modload.RootMode to modload.NeedRoot reports an error when no
go.mod file is present.
Change-Id: I1daa8d2971cb8658e0c804765839d903734a412e
Reviewed-on: https://go-review.googlesource.com/c/go/+/254369
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
Keep track of whether the -mod flag was set explicitly. When
-mod=readonly is the default, we'll want to adjust our error messages
if it's set explicitly.
Also, register the -mod, -modcacherw, and -modfile flags in functions
in internal/base instead of internal/work. 'go mod' commands that
don't load packages shouldn't depend on internal/work.
For #40728
Change-Id: I272aea9e19908ba37e151baac4ea8630e90f241f
Reviewed-on: https://go-review.googlesource.com/c/go/+/253744
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This change does context propagation (and only context propagation)
necessary to add context to modfetch.Download and pkg.LoadImport.
This was done by adding context to their callers, and then
adding context to all call-sites, and then repeating adding
context to callers of those enclosing functions and their
callers until none were left. In some cases the call graph expansion
was pruned by using context.TODOs.
The next CL will add a span to Download. I kept it out of this
change to avoid making it any larger (and harder to review)
than it needs to be.
Updates #38714
Change-Id: I7a03416e04a14ca71636d96f2c1bda2c4c30d348
Reviewed-on: https://go-review.googlesource.com/c/go/+/249021
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
This reverts the following changes:
• cmd/go: add tracing for querying and downloading from the proxy
CL 242786, commit 1a3558341860357c2400e37773e5076bb3a51628
• cmd/go: do context propagation for tracing downloads
CL 248327, commit c0cf190d226cc3defb71d17c01d0b45bf49a8a85
• cmd/go/internal: remove some users of par.Work
CL 248326, commit f30044a03bc7cf107dbec03c02fb6d0072878252
Reason for revert: broke linux 386 and amd64 longtest builders.
The problem started with CL 248326, but CL 248327 and CL 242786
are reverted as well due to conflicts.
Updates #38714.
Fixes #40861.
Change-Id: I68496b4e5a27e47a42183553c3a645b288edac83
Reviewed-on: https://go-review.googlesource.com/c/go/+/249017
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This change does context propagation (and only context propagation)
necessary to add context to modfetch.Download and pkg.LoadImport.
This was done by adding context to their callers, and then
adding context to all call-sites, and then repeating adding
context to callers of those enclosing functions and their
callers until none were left. In some cases the call graph expansion
was pruned by using context.TODOs.
The next CL will add a span to Download. I kept it out of this
change to avoid making it any larger (and harder to review)
than it needs to be.
Updates #38714
Change-Id: I5bf2d599aafef67334c384dfccd5e255198c85b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/248327
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
modfetch.WriteGoSum now accepts a map[module.Version]bool parameter.
This is used to prevent some new sums from being saved to go.sum when
they would be removed by the next 'go mod tidy'. Previusly, sums were
saved for modules looked up during import resolution.
A new function, modload.TrimGoSum, is also introduced, which marks
sums for deletion. 'go mod tidy' now uses this. The new logic
distinguishes between go.mod sums and content sums, which lets 'go mod
tidy' delete sums for modules in the build graph but not the build
list.
Fixes #31580
Fixes #36260
Fixes #33008
Change-Id: I06c4125704a8bbc9969de05265967ec1d2e6d3e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/237017
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
One small step to start propagating the context in
cmd/go for tracing purposes.
Updates #38714
Change-Id: Ibb6debeb9233f84d55f0e81244487355cbe7b82c
Reviewed-on: https://go-review.googlesource.com/c/go/+/237684
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This change adds the -modfile flag to module aware build commands and
to 'go mod' subcommands. -modfile may be set to a path to an alternate
go.mod file to be read and written. A real go.mod file must still
exist and is used to set the module root directory. However, it is not
opened.
When -modfile is set, the effective location of the go.sum file is
also changed to the -modfile with the ".mod" suffix trimmed (if
present) and ".sum" added.
Updates #34506
Change-Id: I2d1e044e18af55505a4f24bbff09b73bb9c908b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/202564
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>
|
|
Running `go mod init` outside of GOPATH with `GO111MODULE=off`
silently fails. This behavior was undocumented.
This CL makes go mod fail with the error:
go: modules disabled by GO111MODULE=off; see 'go help modules'
Comparing with already erroring GO111MODULE=<value> conditions:
* With GO111MODULE=auto, inside GOPATH:
go modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'
* With GO111MODULE=auto outside of GOPATH:
go: cannot determine module path for source directory /path/to/dir (outside GOPATH, no import comments)
Fixes #31342
Change-Id: I749787d2a8640913c4ac263072d051314d76e778
GitHub-Last-Rev: b38447457d8cabed367ea4872cf7f238a49539c7
GitHub-Pull-Request: golang/go#31255
Reviewed-on: https://go-review.googlesource.com/c/go/+/170697
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
To prevent confusion, go mod init should not allow version strings in
the module path when provided as an argument. Instead, fail with a
useful error message.
Fixes #28803
Change-Id: I59272a91b042e32cef33c2e2116f760ca1def218
Reviewed-on: https://go-review.googlesource.com/c/150018
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
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>
|
