Skip to content

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

Closed

Description

@bcmills

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)

Activity

  1. added this to the Go1.17 milestone on Jan 14, 2021
  2. added
    early-in-cycleA change that should be done early in the 3 month dev cycle.
    NeedsFixThe path to resolution is known, but the work has not been done.
    on Jan 14, 2021
  3. bcmills commented on Jan 14, 2021

    @bcmills
    ContributorAuthor

    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.

  4. ianlancetaylor commented on Jan 14, 2021

    @ianlancetaylor
  5. bcmills commented on Jan 14, 2021

    @bcmills
    Author
  6. andig commented on Jan 14, 2021

    @andig
    Contributor

    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.

  7. luantak commented on Jan 17, 2021

    @luantak
  8. bcmills commented on Jan 17, 2021

    @bcmills
    Author
  9. gopherbot commented on Feb 24, 2021

    @gopherbot
    Contributor

    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.

  10. ohir commented on Feb 27, 2021

    @ohir

    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".

  11. dmitshur commented on Mar 25, 2021

    @dmitshur
    Member

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

  12. self-assigned this
    on Mar 25, 2021
  13. gopherbot commented on Mar 30, 2021

    @gopherbot
    Contributor

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

  14. 52 remaining items

  15. gopherbot commented on Oct 12, 2021

    @gopherbot
    Contributor

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

  16. gopherbot commented on Oct 21, 2021

    @gopherbot
    Contributor

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

  17. locked and limited conversation to collaborators on Jun 23, 2023
  18. added a commit that references this issue on Apr 29, 2024
    ced0fdb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions