> "What I would expect with 'go test ./...' is behavior similar to what I had before modules."
Hi John, all, Just to expand slightly on the points from Dave, Scott, and Paul... I suspect part of what you are encountering is that in general: 1. Modules are opt-in for Go 1.11, so by design old behavior is preserved by default. This has a few implications, including you get old behavior by default inside GOPATH, but that only applies if you haven't explicitly forced non-default behavior via GO111MODULE. (In your case, you started with GO111MODULE=on set, so that is part of why you are not seeing the old behavior you are used to). 2. Most of the modules-specific behavior requires that you be "inside" a module (that is, inside a file tree with a go.mod). A consequence of #2 is that if you explicitly ask for modules-specific behavior (e.g., via setting GO111MODULE=on) but are *not* inside a file tree with a 'go.mod' file, then you might see an error message that effectively tells you need to be inside a module. In your case, I think that is why you saw the error "go: cannot determine module path for source directory" when you tried one of your early go commands with GO111MODULE=on but were outside of a file tree with a 'go.mod' file. In addition, I think in a module-world, something like 'go test ./...' only tests the active module(s), and won't traverse down into an unrelated module that happens to be in a sub-directory of the current module. I believe the doc says that explicitly for a '...' pattern appearing in 'go list', and I think that is true beyond just 'go list', at least as far as I am aware: >From https://tip.golang.org/cmd/go/#hdr-List_packages_or_modules 'go list' documentation: "The main module is the module containing the current directory. The active modules are the main module and its dependencies." and "The special pattern "all" specifies all the active modules, first the main module and then dependencies sorted by module path. A pattern containing "..." specifies the active modules whose module paths match the pattern." I think that explains at least one of the examples you sent where 'go test ./...' did not work as you expected when modules were enabled (because in module-mode, './...' won't match modules that are not dependencies of the current module, even if they are in sub-directories, because they would not be part of the current "active modules"). One related item I'll mention is that a nice part of the modules work is that 'go test all' has been re-defined to be more useful to include all the packages in the current module, plus all the packages they depend on (in other words, all direct and indirect dependencies of the current module). If you want to test the current module and all of its dependencies, 'go test all' would do that (rather than 'go test ./...'). In any event, I am just a member of the community and we are all still learning about modules, so I would be happy to learn if any of what I outlined above doesn't line up with what you are seeing... Finally, I'm not sure what would be going on with the last piece you reported where 'go env GOMOD' returned the path to a deleted 'go.mod' file. Best, thepudds On Friday, September 21, 2018 at 11:31:44 AM UTC-4, John wrote: > > Paul, thanks for the explanation. But I think maybe either I'm missing > something or I'm not explaining something correctly. > > What I would expect with "go test ./..." is behavior similar to what I had > before modules. That behavior would be that the go tool would recursively > run all tests from the directory I am in and below it, regardless if there > was a package in the current directory. > > I built your example, which works exactly as you expect. But it doesn't > solve my issue, which is around "go test ./..." recursively. As I go back > up the hierarchy, if I do a go test ./..., it fails. I could always test > by just going into the package and running "go test". I want to be able to > recursively run tests as the current behavior allows with GOPATH. If this > recursive use of "./..." is going away with mod files, then I have to > adjust to making smart tools. But I've got to imagine that this isn't the > intention or that I am still doing something incorrectly. > > Additionally, I have also tried to add go.mod files in sub directories > that contain no go files between the root and the package. This did not > work either. > > Thanks to everyone (Paul, Dave, Scott) who looked at this. > > *Sidenote on my original directory(bug?):* > Interestingly enough, I have made a top level mod file and put a "hello > world" main.go file. That did not make this work. > But what looks like a bug is that I deleted both of those files, but if I > run "go env GOMOD" at src/, I get back a path to a go.mod file that is the > one I deleted. > Running "go mod tidy" gave the same error, so no auto cleanup > And go init mod also throws the same error. > > I'm sure I can clean this up by removing some cached file somewhere. > > On Friday, September 21, 2018 at 12:48:13 AM UTC-7, Paul Jolly wrote: >> >> John, >> >> Scott is on the money with this response: >> >> > I think you need to have a main module defined so there must be a >> go.mod in cwd or upwards >> >> The way to ensure that you are in a valid module context is simply: >> >> go env GOMOD >> >> which will return the path to the current (or main) module context >> (go.mod) if: >> >> a) you are in module mode (either by being outside of GOPATH or with >> GO111MODULE=on) and >> b) there is a go.mod on the directory path from $PWD to the root. >> >> As you have set GO111MODULE=on you can put your source code pretty >> much anywhere you like; even within your GOPATH (whether GOPATH is set >> or not, in the latter case as has been pointed out it defaults to >> $HOME/go) >> >> All you are missing is a go.mod file (go end GOMOD would confirm this, >> and would return "") >> >> Here's a simple example that shows things working within GOPATH: >> >> $ export GO111MODULE=on >> $ export GOPATH=/tmp/tmp.JJgvIDI0Uc >> $ cd /tmp/tmp.In4INnkIH0 >> $ mkdir -p src/example.com/blah >> $ cd src/example.com/blah/ >> $ cat <<EOD >main.go >> package main >> func main() {} >> EOD >> $ go env GOMOD >> >> $ go list >> go: cannot find main module; see 'go help modules' >> $ go mod init example.com/blah >> go: creating new go.mod: module example.com/blah >> $ go env GOMOD >> /tmp/tmp.In4INnkIH0/src/example.com/blah/go.mod >> $ go list >> example.com/blah >> $ go test >> ? example.com/blah [no test files] >> >> >> Paul >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
