# golang/go

Open
opened this Issue Feb 16, 2016 · 10 comments

Projects
None yet
3 participants

### perillo commented Feb 16, 2016

 Suppose you want to implement a tool like golint using go list. When reporting a problem, golint prints the full path to a source file, but when the user specified a relative import path, golint prints a relative path. Unfortunately the Package struct returned from go list does not allow this. The only way to obtain a full path to a .go source file is to use the Dir field, but this is always an absolute path. The Package struct used by go list should have the following additional fields: Cmdline bool json:",omitempty" // defined by files listed on command line Local bool json:",omitempty" // imported via relative local path (./ or ../) SrcDir string json:",omitempty" // a local relative path is interpreted relative to SrcDir

Contributor

### rsc commented Feb 16, 2016

 I don't think I understand what is being requested. As I understand it, all the information being requested is already easily derived from what is reported already: p.Cmdline = p.ImportPath == "command-line-arguments" p.Local = strings.HasPrefix(p.ImportPath, "_/") p.SrcDir = p.Dir

### perillo commented Feb 16, 2016

 p.ImportPath == "command-line-arguments" is not documented, and it is not part of the API. go list -f '{{.ImportPath}}' . prints, as an example, github.com/perillo/goprint, not _/github.com/perillo/goprint p.SrcDir was a mistake. What I want is the raw import path as specified on the command line. As an example go list -f '{{.Path}}' ../... will print ../pkg1 and so on. The raw import path is necessary, IMHO, to correctly report relative paths to source files, as it is done by the golint command.
Contributor

Contributor

### rsc commented Feb 16, 2016

 On golang-dev you asked: It is possible that I'm misunderstanding what "local" means, for the go tool. The default for imports in Go is to be "absolute" or "fully-qualified" in the sense that import "X" has a fixed meaning regardless of the directory in which it appears (ignoring vendoring). Within GOROOT and GOPATH, this is the only permitted import form. Outside GOROOT and GOPATH, mainly to allow simple experiments and throwaway programs, the go command permits an import to use a relative import path like "./X", which obviously changes meaning based on the directory in which it appears. But directory a/b/c might import "./d" and directory a/b might import "./c/d" and directory a/b/c/x might import "../d" and those all refer to the same directory, so internally the go command must construct one canonical import path for that directory. The path it constructs is _/, which you see, for example, in the output of go list. The go command refers to packages found outside GOROOT/GOPATH as "local", in the sense that they are not part of the GOROOT/GOPATH space. Code in GOROOT/GOPATH needs to be self-contained, so it cannot import local packages, although of course imports in the other direction are fine. All that concerns import paths found in import statements in source code. The go command line processes import paths as well, and there it is convenient to allow mentioning a directory (for example, in GOROOT/src/io, saying . or ./ioutil) as a shorthand for the standard, absolute import path of that directory (for that example, io or io/ioutil). The shorthand is limited to command line argument processing. The code in GOROOT/src/io cannot import "./ioutil".
Contributor

### perillo commented Feb 16, 2016

 This is my latest informal patch to add Path and Cmdline fields to the Package struct: http://pastebin.com/Zkr1yevd I don't know if it is worth the additional complexity; probably not. If there is interest I can create a CL, but I'm fine if this issue is closed.