> "I imagine I might be in the minority in using test this way. Its useful when you have a small monorepo to do tests. People who run large monorepos must have advanced tooling and individual modules won't notice the behavior change." Hi John, Stepping back, one side question: how many modules (`go.mod` files) do you have in your single repo? The easiest approach (especially to start) is to have a single module / single `go.mod` file at the root of a repo. That simplifies working with modules overall, and the official modules proposal predicts that most projects will have a single module per repo. That might or might not help the specific issue you raised in this thread, but it very likely would simplify other aspects of your workflow.
In terms of your other comment here: > "But this thread was about if this was expected, not if I think it should be changed (I can always open a bug, see if anyone else agrees). It turns out I'm not doing something wrong per say, its just that it doesn't do what I want. I need to adjust my expectations." If you think the current behavior should change, I would encourage you to file an issue. Most important probably is to outline your use case and where the current behavior falls short. In addition, you could optionally suggest some alternatives you might view as better, but most important probably is to outline your use case. Some possible alternatives for module-aware mode might include: 1. 'go test ./...' could be redefined to always traverse down the filesystem directory structure, ignoring module structure completely. 2. behavior #1 could be the behavior when outside of a `go.mod` file tree, but the current behavior for 'go test ./...' could be retained when inside of a `go.mod` file tree. 3. 'go test ./...' could be redefined to only find packages within the current active module (and not dependencies of the current module that happen to be in sub-directories). 4. behavior #1 could be the behavior when outside of a `go.mod` file tree, but behavior #3 could be the behavior when inside of a `go.mod` file tree. There are pros and cons to each of those, but there are also many more options that could be possible. Also, it is of course not just about 'go test ./...' behavior, but also 'go build ./...', 'go list ./...', etc. --thepudds On Friday, September 21, 2018 at 3:41:39 PM UTC-4, John wrote: > > Thanks for the reply. Other that the bug I encountered, this seems to be > the behavior. > > This new "mod" behavior for ./... at least for "go test" seems to be a > step backwards. It assumes a kind of test methodology based around a > certain type of file layout. > If I am at the top of my src/ and I want to test everything underneath, I > can't without adding some tooling. I have to go inside a specific module. > It is nice that it will now test dependencies. I'm somewhat lost to why > the go tool would need to change the behavior for "go test ./...", seems > like adding go.mod wouldn't require this change. > > I imagine I might be in the minority in using test this way. Its useful > when you have a small monorepo to do tests. People who run large monorepos > must have advanced tooling and individual modules won't notice the behavior > change. > > But this thread was about if this was expected, not if I think it should > be changed (I can always open a bug, see if anyone else agrees). It turns > out I'm not doing something wrong per say, its just that it doesn't do what > I want. I need to adjust my expectations. > > > On Friday, September 21, 2018 at 11:05:28 AM UTC-7, thepud...@gmail.com > wrote: >> >> > "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.
