x/vgo: vgo build error "missing go.mod" #23983
Comments
|
Turns out if you don't have the import comment at the top, then vgo doesn't work at least initially. Did you add that to your main package before running vgo? Note there's definitely a usability issue here regardless. |
Yes, the package has the import comment at the top:
So unless vgo is dynamically getting the author and package name by other means, I would assume it is properly pulling that from the |
|
It looks like it might not be handling the Can you make a minimal repro case that just imports this or another import and see if you can duplicate and post as a gist? |
|
I just did some testing and importing just I manually set the pseudo-version to the version from the error output - since the I'll do some more testing over the weekend. |
|
After some further testing, I was able to narrow this down. When importing the packages Importing a package which imports these packages works as well (whether that package has been configured with a The following code will fail, as While importing the package directly works fine: I believe this may be related to the fact that |
|
I have a fairly small example that reproduces the bug: package main // import "github.com/sigma/plop"
import _ "rsc.io/letsencrypt"
func main() {}With that, I obtain the following when I If I look in the cache, I see this: If I manually remove those last 2 lines, then |
|
The last lines probably come from a vendor.json file where package versions don't match within a single logical module. |
|
That doesn't seem to be the case. Here's the point at which
|
|
I think the following proves the version theory? (and provides a smaller repro) |
|
So the problem seems to be that with proper version numbers, I workaround this locally with the following patch. That gets me going, but I strongly suspect it's not correct diff --git a/vendor/cmd/go/internal/modfetch/gopkgin.go b/vendor/cmd/go/internal/modfetch/gopkgin.go
index f3a5987..0cc105a 100644
--- a/vendor/cmd/go/internal/modfetch/gopkgin.go
+++ b/vendor/cmd/go/internal/modfetch/gopkgin.go
@@ -92,6 +92,9 @@ func (r *gopkgin) Tags(prefix string) ([]string, error) {
}
func (r *gopkgin) Stat(rev string) (*codehost.RevInfo, error) {
+ if r.subdir != "" {
+ return nil, fmt.Errorf("subdirs won't work with gopkg.in")
+ }
ghRev, err := r.unconvert(rev)
if err != nil {
return nil, err |
|
The problem is that gopkg.in/square/go-jose.v1/cipher is not a module at all; gopkg.in/square/go-jose.v1 is. https://github.com/rsc/letsencrypt/blob/master/vendor/vendor.json says and it sounds like those are being taken as module paths instead of as plain import paths. |
rsc
added
the
NeedsFix
|
Change https://golang.org/cl/120042 mentions this issue: |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go1.10 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?darwin/amd64
What did you do?
echo >go.mod && vgo buildin project root.What did you expect to see?
Successful build. The project builds successfully via
depwith the following Gopkg.toml file:What did you see instead?
The text was updated successfully, but these errors were encountered: