modules2tuple failed to generate the correct GH_TUPLE line for Azure:go-autorest

[yurivict]

modules2tuple-1.8.0 generated these lines:

		Azure:go-autorest:v0.1.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest/azure/auth \
		Azure:go-autorest:v0.1.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest/azure/cli \
		Azure:go-autorest:v0.1.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest/date \
		Azure:go-autorest:v0.1.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/logger \
		Azure:go-autorest:v0.2.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest/to \
		Azure:go-autorest:v0.4.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest/adal \
		Azure:go-autorest:v0.4.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/tracing \
		Azure:go-autorest:v0.8.0:azure_go_autorest/vendor/github.com/Azure/go-autorest/autorest \

when the correct line is:

		Azure:go-autorest:v13.0.0:azure_go_autorest/vendor/github.com/Azure/go-autorest \

Testcase: dns/coredns version 1.6.2

[dmgk]

It's a limitation of mapping of Go modules to GH_TUPLE mechanism.

https://github.com/Azure/go-autorest is a multi-module repository - all GH_TUPLE entries you listed above are actually separate modules, each one having its own go.mod file (e.g. https://github.com/Azure/go-autorest/blob/master/autorest/azure/cli/go.mod), so they get recorded as such in dns/coredns go.mod. But modules2tuple (currently) doesn't know that they all live in a single Github repo and generates an individual GH_TUPLE entry for each one of them.

Bottom line is that in some cases, modules2tuple output may need some manual cleanup 🙁

[yurivict]

Oh okay then, we will do manual cleanups, it doesn't hurt. :-)