You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)