-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
x/vgo: vgo list fails if there are no source files #25712
Comments
I note there are a number of semi-related issues: https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3Avgo+%22no+source+files+%22 |
"vgo list" is about packages and will remain so (remember, it will be "go list"). That said, there certainly are commands that are not about packages that complain incorrectly about "no Go source files" and we should fix them. That's not unique to list. Let's make different issues for different list considerations. I think that covers everything raised here, so I am going to close this issue. |
Makes sense, thanks. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?vgo
version:Does this issue reproduce with the latest release?
Yes, and tip.
What operating system and processor architecture are you using (
go env
)?What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
Something like:
What did you see instead?
As I understand it, there is no requirement for a Go module to contain source code; it could just be a parent of submodules.
I wonder whether this issue could/should be broadened to be "fully define semantics of vgo list" to include:
vgo list -t example.com/hello/vX
-deps
and-test
flags from tipvgo list
should ever create ago.mod
if it doesn't existvgo list
should have a mode which doesn't try to do any resolution/downloading and instead errors in case something doesn't fully resolve, so that tools depending on its output don't block for potentially long periods of time, or barf on non-JSON outputThe text was updated successfully, but these errors were encountered: