proposal: x/tools/go/analysis: add GoMod field to Pass.Module

[AkihiroSuda]

Proposal Details

Currently, https://pkg.go.dev/golang.org/x/tools/go/analysis#Module lacks GoMod string (path to go.mod) that is present in https://pkg.go.dev/golang.org/x/tools/go/packages#Module .

My proposal is to expose GoMod in https://pkg.go.dev/golang.org/x/tools/go/analysis#Module so that linter implementations can determine the path of go.mod.

go.mod (w/ go.sum in the same dir) is needed by my linter https://github.com/AkihiroSuda/gosocialcheck to check the reputation of dependencies.

[gopherbot]

Change https://go.dev/cl/676455 mentions this issue: go/analysis: expose GoMod to Pass.Module

[adonovan]

This seems reasonable; the proposal that added Module originally included a whole lot of fields, but this was reduced to just three during review, reserving the option to add more later. We should ask: what other Module fields should we add while we're at it? Dir?

That said, I think you can easily deduce the value of Module.Dir today from the available information by taking the directory of an arbitrary file in the package, removing the Module.Version suffix if present, then removing the suffix that is TrimPrefix(Package.Path, Module.Path). The value of GoMod is then just filepath.Join(Module.Dir, "go.mod").

[AkihiroSuda]

This seems reasonable; the proposal that added Module originally included a whole lot of fields, but this was reduced to just three during review, reserving the option to add more later. We should ask: what other Module fields should we add while we're at it? Dir?

If we are going to add Dir, GoMod might not be needed, as it can be just easily resolved as filepath.Join(Dir, "go.mod").
(Why does https://pkg.go.dev/golang.org/x/tools/go/packages#Module have both Dir and GoMod?)

That said, I think you can easily deduce the value of Module.Dir today from the available information by taking the directory of an arbitrary file in the package, removing the Module.Version suffix if present, then removing the suffix that is TrimPrefix(Package.Path, Module.Path). The value of GoMod is then just filepath.Join(Module.Dir, "go.mod").

This doesn't seem to work, as Pass.Pkg.Path() is a package path (github.com/OWNER/REPO/pkg/...), not a filesystem path.
https://pkg.go.dev/golang.org/x/tools/go/analysis#Pass

A workaround would be to guess the dir from Pass.Fset filenames.

[adonovan]

Why does https://pkg.go.dev/golang.org/x/tools/go/packages#Module have both Dir and GoMod?

I'm not sure, but my guess is that the GoMod file is set iff the go.mod file is available, and the Dir is set if the entire module source tree is available; a module for which we have metadata but not source, for example because we only need to compute the build list (aka MVS constraint solution), would not have a Dir. But for the analysis framework it is safe to assume we have source.

That said, I think you can easily deduce the value of Module.Dir today from the available information by taking the directory of an arbitrary file in the package, removing the Module.Version suffix if present, then removing the suffix that is TrimPrefix(Package.Path, Module.Path). The value of GoMod is then just filepath.Join(Module.Dir, "go.mod").
This doesn't seem to work, as Pass.Pkg.Path() is a package path (github.com/OWNER/REPO/pkg/...), not a filesystem path.

Understood. Here's what I meant with an example:

• /home/me/work/xtools/gopls/internal/golang/foo.go is an arbitrary file.
• /home/me/work/xtools/gopls/internal/golang is its directory.
• golang.org/x/tools/gopls/internal/golang is its Package.Path
• golang.org/x/tools/gopls is its Module.Path
• TrimPrefix(Package.Path, Module.Path) gives you internal/golang.
• Removing this from the directory gives you /home/me/work/xtools/gopls, which is the Module.Dir.
• Appending go.mod gives you /home/me/work/xtools/gopls/go.mod, which is the Module.GoMod.

The version suffix is left as an exercise.