go: cmd/go: "malformed import path" in Go 1.16 for packages with path elements containing a leading dot

It sounds like this issue is affecting more people than we’d hoped. I’ll look at relaxing the constraint that import paths can’t have path elements starting with dots. We’ll aim to backport that to 1.16.1.

We’ll continue to disallow trailing dots in import path elements, since those names aren’t allowed on Windows. We’ll also continue disallowing leading dots in module path elements.

If we find more severe examples after the release, we can consider whether to relax the check in Go 1.16.1. If you are affected, please comment on this issue with the affected module path(s) and versions.

The Gardener project (https://github.com/gardener) is affected by this change, too. We use modules to define cross repo dependencies in the Gardener org, also some of the modules don’t contain Go code at all: For example, https://github.com/gardener/gardener/tree/master/.github/ISSUE_TEMPLATE allows us to re-use Github templates across our repositories with the same dependency management tool (go mod) already used for Go dependencies.

I think we should keep this open since it used to work, and in most other situations, the go command allows a package with an invalid import path to be named using a file path. Probably not for 1.16 at this point in the freeze though.

@odeke-em, I don’t think this issue should be rolled forward to Go 1.17 since we don’t plan to do anything more about it. Perhaps it should just be closed, but we discourage folks from commenting on closed issues and we are actually interested in receiving comments about concrete examples here.

Maybe Unplanned is the right milestone for that.

I did some investigation, and found that the prohibition on leading-dot elements was added in CL 124378, back in July 2018.

We attempted to investigate the prevalence of these paths in the wild using the pkg.go.dev index, but it does not index imports of these paths (which further argues for disallowing them — so far no one seems to have reported the packages as missing there).

The only specific affected module we know of so far is go.uber.org/cadence, but because the affected import statement is an internal package it could be fixed for external consumers by an internal-only change within a patch release for that module (namely, moving the packages currently in the .gen subdirectory to another location and updating the imports within the module).

After discussion with @rsc, @jayconrod, and @matloob, we’re planning to leave this validation in place for Go 1.16.

If we find more severe examples after the release, we can consider whether to relax the check in Go 1.16.1. If you are affected, please comment on this issue with the affected module path(s) and versions.

For a bit of context, I’m doing this because having a go:generate directive within $modroot/.github/workflows aligns the location of the directive with the target of the generation step. However, the argument against this is precisely the point that @bcmills makes - a simple go generate ./... doesn’t end up running this directive. Rather awkwardly I actually use another go:generate directive in another package to run the “hidden” one, which kind of defeats the purpose. So whilst the original goal was perhaps admirable/sensible, the workaround arguably makes it more confusing/convoluted. Which perhaps points to this being a bad idea generally, and hence one that we should not support.

I’ll leave it to @bcmills and @jayconrod to determine whether it’s necessary to continue supporting this pattern given it used ti work in 1.15x or not. From my perspective I think you’ve helped talk me round so this issue can otherwise be closed 😄

Hrm, I’m not sure. We disallow a leading dot in general because it can make code harder to audit: in environments that hide dotfiles by default we don’t want to hide the source code for the dependencies of a Go package, and path elements beginning with _ and . are ignored by go mod tidy and go list ./... (compare #37376).