cmd/go: go mod tidy updates a dependency unnecessarily #33771
Comments
|
In my statements above I misunderstood the behavior of Using the command It states there's a dependency on v0.3.1, but |
Um... I think you're mistaken?
The |
We certainly do need better diagnostics for “why is this module at this version?”. That's #33124. (CC @jayconrod @jadekler) |
|
As far as I can tell this is working as designed: Please investigate using |
bcmills
added
modules
NeedsInvestigation
|
@bcmills Thanks for responding so fast! Thanks for pointing out my mistake. The issue isn't with resolving the dependency for cobra, because you're correct that cobra I need to dig deeper because before running I'll investigate further and come back to here when I know more. |
|
I managed to through a series of I've discovered a new situation though in the same repository where To reproduce: This looks like a bug to me. |
|
Doh, I posted that after hours of 👀 and figured out what's happening a few minutes after posting. But I only figured it out after attempting the process in go1.12.9, which had different logs and those logs pointed to me what was happening. In the When I ran the When I ran the That log line was the clue to point to where the dependency was coming from. So I think this issue can be closed, because the tidy command is upgrading the minimums to what the minimum actually is based on the dependency graph's full state, but the |
#33284 should help with that.
Note that
|
|
It sounds like We certainly do appreciate the feedback about sources of confusion, though — hopefully fixes for the other issues linked above will help with that. |
|
I've got another case where To reproduce: My assumption was that there must be a dependency that needs this version. I figured there must be another dependency, so instead I used this From best I can tell the only packages dependent on
The only dependency doesn't have a I've iterated through all the commits in the The commit before that commit when Am I missing something? It seems like |
|
I realize the go list command I included above didn't look for usage in tests, xtests, or for all dependencies, but when I add those things it doesn't show up any new packages: |
|
I've discovered why this is happening, and I suspect it will be difficult for Via
|
…d2 (#1679) Update `github.com/rcrowley/go-metrics` for transition to Modules (#1634). From: rcrowley/go-metrics@a5cfc242a56b To: rcrowley/go-metrics@51425a2415d2 Diff: rcrowley/go-metrics@a5cfc24...51425a2 (41 commits) To make the transition to Modules possible. Some dependencies at their current version have incompatible relationships with other dependencies we have. Dep was more tolerant to incompatible versions than Modules. Making this change ahead of the PR that switches us to Modules makes that PR a functional no-op. The reason Modules is updating `go-metrics` is because the monorepo is also dependent on `github.com/ethereum/go-ethereum` which is in turn, via it's tests, dependent on the `exp` sub-package within `go-metrics`. The sub-package was added in rcrowley/go-metrics@51425a2. The `go` tool in this situation will automatically upgrade `go-metrics` to it's latest revision since it can see the `exp` is available there. This PR is however upgrading to the first or oldest revision that contains the sub-package we need to satisfy Modules. We could upgrade to the latest revision but the changes in the smaller diff are much less significant and pose a smaller risk than the changes that are in the diff (rcrowley/go-metrics@a5cfc24...cac0b30 144 commits) to take us all the way to latest. More details about how this was discovered can be found here: golang/go#33771 (comment)
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I initialized a new Go module in a repository that had a dep
Gopkg.tomlandGopkg.lockwhile attempting to upgrade a repo from dep to modules (stellar/go#1634).What did you expect to see?
I expected to see no changes to
go.modbetween a go mod init and a go mod tidy, because the file should be tidy already, as it was just created.What did you see instead?
The
go.modfile contains in 122 changes, many involving appending// indirect. The change I'm particularly concerned with is where a dependency is being updated unnecessarily.After the
go mod init, this dependency was included, which is expected:After the
go mod tidy, that dependency was changed to its latest tagged version:The
go mod tidyadded dependencies from test files, which were pruned in the originalGopkg.*files, so I understand there should be some changes and additions. But when I askgo mod whyabout the dependency, the only package using the dependency is not a test dependency:I don't see a reason why the
go mod tidywould have updated the dependency since there are no new test packages dependent on it that might have had a higher required version defined.Interestingly if I change the version back and runI must have made a mistake, as when I run it a second time now, it changes it.go mod tidya second time, the file stays unchanged.The text was updated successfully, but these errors were encountered: