-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: list the Go resources in a physical directory #30469
Comments
I suspect that the command you're looking for is: go list -f '{{.Dir}}' $(dirname $(go env GOMOD))/... |
Hmm, that's not strictly sufficient, though: it won't tell you what |
Related #28835 |
Hum, unless I'm missing something:
So you probably need to switch to the module directory root (because otherwise
which is not terribly convenient (and it is not even complete, there are other kinds of source files to add) And having to os.exec |
seems like nobody else needs this, and i believe zip contents need to be ~everything to match modules sums. |
go 1.11/1.12
A lot of Go projects have been using the historical unpacked filesystem property of GOPATH to mix Go source files with other things (human documentation md files, non-Go resource files, etc).
This mixing does not make sense in module mode, since the Go compiler is the only thing that is smart enough to locate and access the content of module zip files.
Therefore there is a need to inspect existing Go project trees, to separate Go project source files from other things. And you have a bootstrapping problem, because GOPATH is not used in module mode, and the whole point of the inspection is to sort what must end up in the zip files, and what should end up elsewhere, so at this point the project is no longer in GOPATH but not in a zip module yet.
Is there a way to ask Go
"tell me what part of this directory is useful to the builder and should end up in a zip module, and what part needs to be exposed some other way?"
Aside from calling
exec.Command("go", "list", "-f"…, ".")
recursively that is?(Of course one could just zip brutally the whole tree and look what breaks afterwards, but that is not a very efficient way to switch to modules)
The text was updated successfully, but these errors were encountered: