This is because ../a/b is interpreted as a relative package path rather than a relative file path, I think.
What should happen in the analogous situation where the module is located at ./a/b and the user runs go list ./a/b?
Should that also be interpreted as a file path?
What if the path includes a ... wildcard, such as ./a/b/... or ./a/... or ../a/... or ../a/b/...?
../a/b is being interpreted as a file path; the problem is with file paths into nested replacement modules in general. I get the same error with an absolute path.
Listing a package in example.com/a works:
$ go list ../a
The wildcard causes a different error, whether or not the module is in a nested replacement. This might be WAI though.
$ go list ../a/...
pattern ../a/...: directory /Users/jayconrod/Code/test/a is outside module root (/Users/jayconrod/Code/test/m)
$ go list ../a/b/...
pattern ../a/b/...: directory /Users/jayconrod/Code/test/a/b is outside module root (/Users/jayconrod/Code/test/m)
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
Create three local modules: M (main module, requiring and replacing the other two), A (module in a directory outside M), and B (module in a subdirectory of A).
Attempt to list a package in B using a relative or absolute file path.
What did you expect to see?
Package name is printed successfully:
What did you see instead?
The text was updated successfully, but these errors were encountered: