Extract canonical import path from .go files

[jayconrod]

Migrated from bazelbuild/rules_go#874

See https://golang.org/doc/go1.4#canonicalimports

Go implementation: findImportComment

[psalaberria002]

Is there any workaround for this? I just hit the issue when importing https://github.com/open-telemetry/opentelemetry-go/blob/v1.5.0/exporters/otlp/otlptrace/internal/otlpconfig/envconfig.go#L15

[purkhusid]

I'm hitting the same issue when trying to use OpenTelemetry packages. Are ther any known workarounds?

[psalaberria002]

I'm hitting the same issue when trying to use OpenTelemetry packages. Are ther any known workarounds?

I think it got fixed for us when we upgraded to the latest version.

$ cat go.mod | grep opent
        go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin v0.40.0
        go.opentelemetry.io/otel v1.14.0
        go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.14.0
        go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.14.0
        go.opentelemetry.io/otel/sdk v1.14.0
        go.opentelemetry.io/otel/trace v1.14.0
        github.com/opentracing/opentracing-go v1.2.0 // indirect
        go.opentelemetry.io/otel/exporters/otlp/internal/retry v1.14.0 // indirect
        go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.14.0 // indirect
        go.opentelemetry.io/proto/otlp v0.19.0 // indirect

[jayconrod]

This issue shouldn't be relevant anymore now that GOPATH is mostly dead.

It was referring specifically to comments like this:

package otlpconfig // import "go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig"

Before Go modules, the go tool checked that if the canonical import path was set, it matched the directory within $GOPATH. It was possible to download a package to the wrong path manually or by using a non-canonical path that mapped to the same repository like github.com/open-telemetry/opentelemetry-go.

This issue was meant to add that feature to Gazelle, but since GOPATH is basically deprecated, and modules don't support canonical import paths (the module path in go.mod serves that purpose), this feature isn't needed.