You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The background:
One of the direct dependencies of the project has an indirect dependency of bitbucket.org/ww/goautoneg but it turns out that this project has been removed/abandoned recently.
Moreover, all the dependencies are vendored and despite the fact that operator-sdk requires a whole chain of its own dependencies the aforementioned bitbucket.org/ww/goautoneg is not actually needed or used since I can't find it in the vendor directory.
Thus the project can be built without issues because all the dependency requirements are met but the go mod commands are not working since they cannot find the repository with bitbucket.org/ww/goautoneg
This issue looks similar to #26602 but the problem is more subtle. While one of the declared indirect dependencies is actually missing we are not using it anyway.
It would be great to allow similar best effort strategy for other go mod subcommands. Because currently if some indirect dependency cannot be loaded or resolved none of the commands can be used. They just print out the failing subtree and exit.
What did you expect to see?
$ go mod verify -e
not all modules verified
go: github.com/operator-framework/operator-sdk@v0.10.0 requires
github.com/operator-framework/operator-lifecycle-manager@v0.0.0-20190128024246-5eb7ae5bdb7a requires
github.com/operator-framework/operator-registry@v1.0.4 requires
github.com/operator-framework/operator-lifecycle-manager@v0.0.0-20190105193533-81104ffdc4fb requires
bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: reading https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 404 Not Found
$ # does best effort package verification ignoring the failing path.
What did you see instead?
$ go mod verify
go: github.com/operator-framework/operator-sdk@v0.10.0 requires
github.com/operator-framework/operator-lifecycle-manager@v0.0.0-20190128024246-5eb7ae5bdb7a requires
github.com/operator-framework/operator-registry@v1.0.4 requires
github.com/operator-framework/operator-lifecycle-manager@v0.0.0-20190105193533-81104ffdc4fb requires
bitbucket.org/ww/goautoneg@v0.0.0-20120707110453-75cd24fc2f2c: reading https://api.bitbucket.org/2.0/repositories/ww/goautoneg?fields=scm: 404 Not Found
The text was updated successfully, but these errors were encountered:
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 env
OutputWhat did you do?
Tried to verify and tidy go modules.
The background:
One of the direct dependencies of the project has an indirect dependency of
bitbucket.org/ww/goautoneg
but it turns out that this project has been removed/abandoned recently.Moreover, all the dependencies are vendored and despite the fact that operator-sdk requires a whole chain of its own dependencies the aforementioned
bitbucket.org/ww/goautoneg
is not actually needed or used since I can't find it in the vendor directory.Thus the project can be built without issues because all the dependency requirements are met but the
go mod
commands are not working since they cannot find the repository withbitbucket.org/ww/goautoneg
This issue looks similar to #26602 but the problem is more subtle. While one of the declared indirect dependencies is actually missing we are not using it anyway.
This change https://go-review.googlesource.com/c/go/+/255960/ introduces the
-e
flag tomod tidy
andmod vendor
commandsIt would be great to allow similar best effort strategy for other
go mod
subcommands. Because currently if some indirect dependency cannot be loaded or resolved none of the commands can be used. They just print out the failing subtree and exit.What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: