/ go Public
cmd/go: add 'go get' options to update direct and indirect dependencies separately #28424
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
Users have more familiarity with their direct dependencies than their indirect dependencies. Indirect dependencies can also be larger in number, with greater potential combinations of pair-wise versions.
For these and other reasons, upgrading direct dependencies has a different risk profile than upgrading indirect dependencies.
This might result in upgrade strategies that retain more benefits of 'High-Fidelity Builds', especially as compared to doing a simple
go get -uor
go get -u=patch.
Regardless of whether or not this particular suggestion ends up making sense, a more general goal would be to have a small basket of easy-to-run upgrade strategies that could be applied to something like 80-90% of projects.
The "Update Timing & High-Fidelity Builds" section of the official proposal includes:
This is a very nice set of properties of the overall modules system, and is materially different than a more traditional approach.
That section later goes on to say:
The initial starting point for a new set of dependencies in the modules system is more conservative than a more traditional approach, and as a result it is likely the case that you have better odds of starting with a working system. The ability to easily do
go get -uto update all direct and indirect dependencies helps balance out that more conservative start.
However, once you do
go get -u, you have stepped away to some degree from some of the benefits of "High-Fidelity Builds" at that point in time.
The same is true of
go get -u=patch, though the step away is smaller.
Consider some form of providing for an easy upgrade just to direct dependencies.
Setting aside the actual mechanics (e.g., new flag vs. some other mechanism), if you could easily ask for to get the latest versions of your direct dependencies, e.g., via something like:
...or less likely, perhaps that same sentiment could be written something like:
...or some other form that would ask to upgrade only your direct dependencies to the latest version available. That would mean in the common case the resulting versions for your indirect dependencies would be the ones listed in a
requiredirective by at least one of your other dependencies, which would preserve many of the benefits of 'High-Fidelity Builds'.
In contrast, a simple
go get -uoften moves your indirect dependencies to versions beyond the versions listed in any
requiredirective, and hence you might be using versions of modules that the module's importer in your build has never used or tested, or you otherwise might find yourself in a rare combination of versions involving indirect dependencies.
The author of the top-level build:
For the rest of this write-up, we'll use
go get -u -directonlyas the strawman form (rather than
go get direct@latest).
go get -u -directonlyor similar could be viewed as a 'high-fidelity upgrade', though that might not be not good terminology.
If some form of mechanics for more easily upgrading direct dependencies was adopted, it could apply for patch upgrades as well, such as something like:
...which would update your direct dependencies to their latest patch releases.
In addition, it might make sense to also allow for easily specifying how you want to upgrade your indirect dependencies. If that was allowed, then for some projects a natural strategy for dependency upgrades might be:
That would more conservative than
go get -u, and slightly more aggressive than the hypothetical
go get -u -directonly, but there is some risk mitigation for indirect dependencies by picking up the latest patch versions for indirect dependencies (
go get -u=patch -indirectonly, which admittedly is not a great flag name).
requirestatements for a module have the true minimum supported version of dependencies
go get -u -directonly,
go get -u=patch -directonly,
go get -u=patch -indirectonlycould provide simpler and better answers to those questions at least for some projects.
I think even today in 1.11 you can emulate the suggested behavior above, though it is not always natural or obvious.
Perhaps there is a simpler way today, but for example given the flexibility of
go list, I suspect in 1.11 the following gives you the
go get -u=patch -indirectonlybehavior described above:
To upgrade your direct dependencies to their latest release (the
go get -u -directonlyor
go get direct@latestbehavior described above), this should work in 1.11:
go mod edit -jsonand similar open up even more doors for greater control today.
The text was updated successfully, but these errors were encountered: