Relative import paths are not resolved to full import paths.

[dmitshur]

For example, if you cd into $GOPATH/src/github.com/gorilla/mux and run:

go list ../../kisielk/gotool/

You get the complete import path github.com/kisielk/gotool as output.

However, with the same current-working directory, running:

gotool.ImportPaths([]string{"../../kisielk/gotool/"})

Returns:

[]string{"../../kisielk/gotool"}

It should be []string{"github.com/kisielk/gotool"}.

[dmitshur]

This may not be a bug but rather intended behavior.

The reason go list ../../kisielk/gotool/ prints the full import path is because it calls build.Import on the relative import path to get a build.Package type and prints its ImportPath field (which is the full import path).

So, I'm not sure if this is a bug or intended behavior. Fixing it simply requires to do more work; it's not a bug in the existing code.

The current documentation does not specify how relative import paths are handled:

// ImportPaths returns the import paths to use for the given arguments.
// The path "all" is expanded to all packages in $GOPATH and $GOROOT.
// The path "std" is expanded to all packages in the Go standard library.
// The string "..." is treated as a wildcard within a path.

@kisielk, is this a bug or intended behavior?

I am leaning towards intended behavior... If so, is there room to expand the API to provide FullImportPaths which is just like ImportPaths, except it also resolves relative import paths to full import paths (if possible) in this package? Or should I place that in another package?

[dmitshur]

I've verified this is not a bug in code by running the func importPaths(args []string) []string from cmd/go (from Go 1.5) code and it has the same behavior, relative import paths are kept as they are (and it doesn't verify that there's an existing package there).

I think this bug can be resolved by updating the documentation. I will make a PR.

[kisielk]

The code in gotool is pretty much copied verbatim from the go sources, so it should behave exactly the same.

[dmitshur]

We should also document what happens when you give an empty slice of arguments.

It returns []string{"."} in that case.

See mdempsky/maligned#5 (comment).