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

cmd/go: deprecate installing binaries using 'go get' in Go 1.17 and make 'go get -d' the default behavior #43684

Closed
bcmills opened this issue Jan 14, 2021 · 46 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Jan 14, 2021

Proposal #40276 added a versioned go install variant that works outside of a module.

As part of the changes approved in that proposal, we plan to deprecate the use of the go get to install binaries, and make go get -d (which downloads source code for but does not build the requested packages) the default behavior.

We had planned to warn about the use of go get to install binaries in Go 1.16 and make it the default in Go 1.17. However, in #42885 we decided to also delay the warning until Go 1.17, so that third-party projects that support the most recent two major Go releases (as the Go project itself does) can give users a single non-deprecated install command, rather than a confusing menu of commands that vary by Go version.

I don't see an issue filed yet to track that change in Go 1.17, so this is that tracking issue. (CC @jayconrod @matloob)

@bcmills bcmills added this to the Go1.17 milestone Jan 14, 2021
@bcmills bcmills added early-in-cycle A change that should be done early in the 3 month dev cycle. release-blocker NeedsFix The path to resolution is known, but the work has not been done. labels Jan 14, 2021
@bcmills
Copy link
Contributor Author

bcmills commented Jan 14, 2021

It is not clear to me whether we should print a deprecation notice in Go 1.17 and change the default behavior in Go 1.18, or change the default behavior in 1.17 and merely print a notice informing the user of the change if their go get pattern happens to match a package main.

@ianlancetaylor

This comment has been minimized.

@bcmills

This comment has been minimized.

@andig
Copy link
Contributor

andig commented Jan 14, 2021

As part of the changes approved in that proposal, we plan to deprecate the use of the go get to install binaries, and make go get -d (which downloads source code for but does not build the requested packages) the default behavior.

I‘m all for this. Its a regular source of confusion that go get fails when I pull the sources for later cross-compile and the go get fails with architecture-specific error messages.

@lu4p

This comment has been minimized.

@bcmills

This comment has been minimized.

@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.17.
That time is now, so a friendly reminder to look at it again.

@ohir
Copy link

ohir commented Feb 27, 2021

change the default behavior in 1.17 and merely print a notice informing the user of the change if their go get pattern happens to match a package main.

The sooner the better. Just add a short instruction for the non-Go user stumbling upon older source that "Since Go 1.17 to install an app from the source you need to use go install instead of go get". I'd also suggest adding the -u flag to the install - silent or with a compact message that "-u is not needed with install".

@dmitshur
Copy link
Contributor

Friendly ping @bcmills, @jayconrod, @matloob since this is a release blocking issue and has an early in cycle label.

@jayconrod jayconrod self-assigned this Mar 25, 2021
@gopherbot
Copy link

Change https://golang.org/cl/305670 mentions this issue: cmd/go: print deprecation notice for 'go get cmd'

@gopherbot
Copy link

Change https://golang.org/cl/305649 mentions this issue: _content/doc: add a page explaining 'go get' deprecation

gopherbot pushed a commit to golang/website that referenced this issue Apr 5, 2021
'go get' will link here when the arguments refer to main packages and
the -d flag is not enabled.

For golang/go#43684

Change-Id: I62045a4451bb767a83d9401665420b164c6ca255
Reviewed-on: https://go-review.googlesource.com/c/website/+/305649
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
gopherbot pushed a commit that referenced this issue Apr 5, 2021
The notice is shown when 'go get' is invoked with the -d flag, and
the arguments match at least one main package.

This reverts CL 274552.

For #43684

Change-Id: I42e6731455f22988bf72dde1d5a76d197e9e3954
Reviewed-on: https://go-review.googlesource.com/c/go/+/305670
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
@fzipp
Copy link
Contributor

fzipp commented Apr 8, 2021

If installing binaries using 'go get' is deprecated, the Go documentation should lead by example and use the recommended 'go install' command. There are:

  • contribute.html
    go get -u golang.org/x/review/git-codereview
    go get -u golang.org/x/tools/cmd/go-contrib-init
    go get -u golang.org/x/review/git-codereview

  • docs.html
    go get golang.org/x/tour

  • install-source.html
    go get golang.org/x/tools/cmd/godoc (x2)

  • manage-install.html
    go get golang.org/dl/go1.10.7

Also, many README files in the Go repositories instruct the user to install binaries using 'go get':

https://github.com/golang/blog
https://github.com/golang/dl
https://github.com/golang/example
https://github.com/golang/lint
https://github.com/golang/perf
https://github.com/golang/review
https://github.com/golang/tools
https://github.com/golang/tour
https://github.com/golang/appengine

@toothrot
Copy link
Contributor

@bcmills We're getting close to the freeze. Just checking in as this issue is both early-in-cycle and a release-blocker. Any updates?

@bcmills bcmills added okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 and removed early-in-cycle A change that should be done early in the 3 month dev cycle. labels Apr 23, 2021
@bcmills
Copy link
Contributor Author

bcmills commented Apr 23, 2021

Jay implemented the deprecation notice in CL 305670. I believe we're planning to actually change the default behavior in 1.18, so I think we're done with the 1.17 parts of this.)

(I'd like to confirm that understanding with Jay after he gets back, though. Leaving as release-blocker and marking okay-after-beta1 to make sure we do that.)

@jayconrod
Copy link
Contributor

@bcmills comment is correct.

I still need to add a release note and update documentation for 1.17. After that, we can re-milestone to 1.18 for the default behavior change.

@gopherbot
Copy link

Change https://golang.org/cl/318570 mentions this issue: cmd/go: don't print a 'go get' deprecation notices in the main module

@pellared
Copy link

Is not the go get approach safer? Does it not validate the modules against go.sum? For sure it is bypassed when using go install.

If what I suspect is true then usage of go install is more vulnerable to supply chain attacks.

gopherbot pushed a commit that referenced this issue Sep 28, 2021
The -d flag has no effect in module mode.

GOPATH tests are left alone.

For #43684

Change-Id: If0f0aad73d8b543ca4058fe9c9fea9d7fd7f95bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/352150
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>
gopherbot pushed a commit that referenced this issue Sep 28, 2021
For #43684

Change-Id: I9ce47de82203ec87e7d3683f56e6c6d61ae255f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/352151
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>
@zikaeroh
Copy link
Contributor

With this deprecated, what is the recommended way to install something like golang.org/x/tools/gopls@master (which has to be built with golang.org/x/tools@master at the same revision) without cloning the repo? See the instructions here: https://github.com/golang/tools/blob/master/gopls/doc/advanced.md#unstable-versions

go install doesn't have a way to specify multiple modules.

Forgive me if this has been brought up before (I can't recall if it has).

@jayconrod
Copy link
Contributor

@zikaeroh This change is admittedly sacrificing flexibility in exchange for simplicity and predictability. go install example.com/cmd@version doesn't support changing versions of dependencies.

For gopls development, and in general when developing tools where a lot of changes are made across multiple modules, I expect the most convenient workflow will be to run go install . within the gopls directory. That will apply the local replace directive, referring to the parent module. Alternatively, a go.work file could be used (#45713).

As a user of a tool, if you want to upgrade dependencies beyond what the tool's go.mod asked for, you can do something like:

# Create an empty go.mod file, only for tracking requirements.
cd $(mktemp -d)
go mod init empty-module-for-installing-a-tool

# Use 'go get' to add requirements and to ensure they work together.
go get golang.org/x/tools/gopls@master golang.org/x/tools@master

# Install using the selected versions in go.mod.
go install golang.org/x/tools/gopls

@zikaeroh
Copy link
Contributor

I see. That's effectively what I do now, I suppose (with https://github.com/zikaeroh/gotools, which does the above for gopls by converting its relative replacements to absolute replacements).

I was hoping to rewrite my tool manager to use go install to avoid having to build temporary go.mod + tools.go files for each binary (since nearly all of the time, there's no point; the tool's go.mod is plenty), but I suppose I can just deal with both.

I'm sure it's rare, I'm just one to always be testing gopls at the latest to report bugs as they appear, and prefer to not have to do something special to run it.

@jayconrod
Copy link
Contributor

@zikaeroh Sorry for the extra trouble. I'm pretty sure we talked about this at some point in #40276, since it would have been easy to interpret arguments the same way go get does. I think we decided not to because it's not clear on the command line whether anything from golang.org/x/tools is actually installed. It might be a main package (installed), a regular package (compiled only? or not?) or a module that just acts as a version constraint. And you don't know which from the command line. With a query like @master it could change over time.

@zikaeroh
Copy link
Contributor

No worries, I do agree that the ambiguity isn't worth it. I just also know that gopls is probably the most important tool I install these days, so wanted to bring it up (especially given official instructions say to use go get in a way that will stop working, and right now spits out an error).

It's not too bad for me to preserve the code that automates that mktemp -d; go mod init process whenever go install wouldn't be enough. Nearly all the knobs I have in GOBIN helper exist just to deal with gopls. 😄

@gopherbot
Copy link

Change https://golang.org/cl/354149 mentions this issue: cmd/go: do not check for a built binary in TestScript/mod_get_fossil

gopherbot pushed a commit that referenced this issue Oct 5, 2021
This test hasn't passed since CL 349997, but the failure was not
detected because the Go project's builders do not have a 'fossil'
binary installed (#48802).

For #43684

Change-Id: I25544574ab48f4f146ae3795e541179e78815758
Reviewed-on: https://go-review.googlesource.com/c/go/+/354149
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
@heschi
Copy link
Contributor

heschi commented Oct 6, 2021

Is this done? What's left to do if not?

@jayconrod
Copy link
Contributor

Implementation work is done. I still need to take a pass through the website and update any go get instructions to go install.

@gopherbot
Copy link

Change https://golang.org/cl/355209 mentions this issue: cmd/go: adjust documentation mentioning 'go get'

@gopherbot
Copy link

Change https://golang.org/cl/355249 mentions this issue: _content: change 'go get' to 'go install' where appropriate

gopherbot pushed a commit to golang/website that referenced this issue Oct 12, 2021
For golang/go#43684

Change-Id: Ifdb0695d15961150960f7be3eb0fb44ac1f0d4d2
Reviewed-on: https://go-review.googlesource.com/c/website/+/355249
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>
gopherbot pushed a commit that referenced this issue Oct 12, 2021
In module-aware mode, 'go get' no longer builds or installs packages.

- 'go generate' explains build commands do not run generate
  commands. 'go get' is no longer a build command, so this CL removes
  mention of it.
- 'go get' will continue to accept build flags, but they're
  ignored. The documentation no longer mentions them, though it does
  mention -x for printing VCS commands.

For #43684

Change-Id: I1eea7241eecf72ba9f98238b729d91cc77ec7665
Reviewed-on: https://go-review.googlesource.com/c/go/+/355209
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>
@gopherbot
Copy link

Change https://golang.org/cl/355493 mentions this issue: cmd/go: stamp tags and flags in build info

@gopherbot
Copy link

Change https://golang.org/cl/357714 mentions this issue: all: update install commands to go install pkg@version

gopherbot pushed a commit to golang/tools that referenced this issue Oct 27, 2021
Updates golang/go#43684
Updates golang/go#49101

Change-Id: I2f0c7920bcd6ce0429f1b7bdda3747bf376775f2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/357714
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
'go get' will link here when the arguments refer to main packages and
the -d flag is not enabled.

For golang/go#43684

Change-Id: I62045a4451bb767a83d9401665420b164c6ca255
Reviewed-on: https://go-review.googlesource.com/c/website/+/305649
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
For golang/go#43684

Change-Id: Ic72fd0b6d1f4ff3262115e1cdaf028c315dc18f8
Reviewed-on: https://go-review.googlesource.com/c/website/+/329500
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>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
In 1.17 users are presented with a deprecation warning when using
go get like this. Now go install is more appropriate.

Fixes golang/go#47939
Updates golang/go#43684

Change-Id: Ia5530cfd432d216029b6618d55488de89eaff835
Reviewed-on: https://go-review.googlesource.com/c/website/+/347211
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Website-Publish: DO NOT USE <dmitshur@google.com>
Trust: Cody Oss <codyoss@google.com>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
'go install' works properly with modules and allows installing
go-contrib-init and git-codereview from anywhere.

Updates golang/go#43684

Change-Id: I69edf897e9ca632f4035facc91303fc1248f9f3c
Reviewed-on: https://go-review.googlesource.com/c/website/+/349249
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
For golang/go#43684

Change-Id: Ifdb0695d15961150960f7be3eb0fb44ac1f0d4d2
Reviewed-on: https://go-review.googlesource.com/c/website/+/355249
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>
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests