Skip to content

cmd/go: get -u updates more in module mode than GOPATH mode #26902

Closed
@bcmills

Description

@bcmills

At the moment go get -u -d . in module mode updates all dependencies of the main module, and as of https://golang.org/cl/128136, go get -u -d $PKG for any package in the main module will do the same.

The current documentation is ambiguous on this point. It says:

The -u flag instructs get to update dependencies to use newer minor or patch releases when available. Continuing the previous example, 'go get -u A' will use the latest A with B v1.3.1 (not B v1.2.3).

[…]

When using -m, each specified package path must be a module path as well, not the import path of a package below the module root.

[…]

With no package arguments, 'go get' applies to the main module, and to the Go package in the current directory, if any. In particular, 'go get -u' and 'go get -u=patch' update all the dependencies of the main module.

The documentation is ambiguous because it does not clarify which “dependencies” go get updates

  • “package dependencies”, the set of modules containing the transitive closure of imports of a package, or
  • “module dependencies” the set of modules that are required by the module containing the package, or
  • something else, such as the union of the package and module dependencies.

My intuition is that, without the -m flag, get -u should update the package dependencies: the user is requesting a specific package, not (necessarily) a module, and because go.mod files are currently very sparse, any given package may have a large number of package dependencies that are not module dependencies. We should not fail to update those dependencies, so we should not upgrade only “module dependencies”. On the other hand, “the union of package and module dependencies” seems more complicated to explain.

If I understand @rsc correctly, (in https://golang.org/cl/128555), he has some other alternative in mind, although I'm not sure which.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.modules

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions