Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/go: go mod init fails to determine module path in subdirectory #27951
Comments
This comment has been minimized.
This comment has been minimized.
Please attach the output of |
This comment has been minimized.
This comment has been minimized.
Which directory (if any) is at the root of your VCS checkout, and what is your |
This comment has been minimized.
This comment has been minimized.
Sorry, only noticed the "operating system" question, added |
This comment has been minimized.
This comment has been minimized.
@bcmills I see this has been scheduled- seems I've hit an actual issue here? |
This comment has been minimized.
This comment has been minimized.
Have you tried |
This comment has been minimized.
This comment has been minimized.
That creates a go.mod:
is this the expected behavior? |
This comment has been minimized.
This comment has been minimized.
You can alternatively provide an explicit argument, as you outlined in #27951 (comment). The bug you correctly identified is that
|
This comment has been minimized.
This comment has been minimized.
It seems to me that |
This comment has been minimized.
This comment has been minimized.
@rfay - what behaviour would you expect if there are multiple remotes? Having
|
This comment has been minimized.
This comment has been minimized.
The remote name "origin" is absolutely arbitrary (although ever-so-widely used), and should not be a fundamental assumption. Just a --remote= arg would solve the problem and make it explicit that |
This comment has been minimized.
This comment has been minimized.
Therefore, I don't think it's accurate to describe
Hence to my mind the current behaviour of |
This comment has been minimized.
This comment has been minimized.
It's good enough for people who already know the idiosyncrasy, not good enough for n00bs like me coming from dep. There will be lots of n00bs. |
This comment has been minimized.
This comment has been minimized.
Being new to go mod, I run into the exact same issue today. It did take me a while googling, with the right combination of key words to finally land in here. The documentation makes sense to me and I'm OK with the implicit dependency of go mod and git. However, I'd suggest (at least) make the error message more meaningful or explicit. It will save quite a bit of time for n00bs. Cheers, |
This comment has been minimized.
This comment has been minimized.
This has bitten me for the second time today. Needs a meaningful error message at the very least |
This comment has been minimized.
This comment has been minimized.
The original issue here seems to rely on the "last resort" guessing the module import path, by detecting a git repo that has a remote named What makes it work in one folder and not the other, is because the detection looks in the current directory for I agree that instead extending and complicating (bloating, as @myitcv says) the guesswork that I find this helpful: https://github.com/golang/go/wiki/Modules#quick-start Should |
This comment has been minimized.
This comment has been minimized.
I changed the wording of the message in CL 166319 to fix #30678 (which I think is a duplicate of this). It now says "cannot determine module path for source directory %s (outside GOPATH, module path not specified)". This suggests that a module path should be specified explicitly without being too wordy. Is this enough info, or should It would be feasible to walk up parent directories, looking at I don't think other VCS support can be added here; the |
This comment has been minimized.
This comment has been minimized.
maybe a hint towards the correct command?
I'd |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
@iWdGo, to be honest, I'm not sure that inferring The right solution might be to remove the |
This comment has been minimized.
This comment has been minimized.
I agree that best effort to locate path is confusing and removal seems most appropriate. A default value set to the folder name where the module resides could be considered but might be the subject of a separate issue. The behavior would become similar to the The discussed message would be irrelevant and could be replaced with "default module path set to ". |
This comment has been minimized.
This comment has been minimized.
Killing the github.com special case seems fine. I would like to leave all the other, better, higher-priority auto-deriving of module paths, since those are much more accurate and helpful. |
This comment has been minimized.
This comment has been minimized.
Change https://golang.org/cl/172019 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
I have been able to resolve this with code in a repo subdir with
Surely this can be automated?! |
This comment has been minimized.
This comment has been minimized.
This solved it for me! Thank you @joshuamkite!! |
This comment has been minimized.
This comment has been minimized.
This solved for me too. Thanks!! |
This comment has been minimized.
This comment has been minimized.
why is go mod init pwd solved? why? |
This comment has been minimized.
This comment has been minimized.
If the |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.11
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?What did you do?
Trying to init go modules, I'm seing it fail from one folder but working from another. Both folders only contain two simple go files: