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.
