Hi @thepudds, Good to hear and glad to have followed up so as to have introduced in the conversation how to address the concern in that post.
Thanks for the great summary of how to give effective feedback about about modules and the general context. Best, Scott On Saturday, 22 September 2018 20:37:51 UTC+2, thepud...@gmail.com wrote: > > Hi Scott, all, > > > "also I think they have obligated themselves to maintaining support > for the current functionality, which some might not > find fitting to the way they work." > > Regarding the concern raised in that post -- I think it is definitely not > too late to give feedback on how modules work, even if the core Go team has > said they will maintain backwards compatibility for modules. > > My understanding of that backwards compatibility is that a module that is > defined today will be understood by future Go releases, but that the > statement of backwards compatibility does not imply that the exact behavior > of modules is frozen (especially for the behavior of the go tool itself, > what flags it supports, what those flags do, what does './...' mean, > etc.). Rather, as far as I understand, the exact behavior is *expected* to > change based on 1.11 feedback. > > For example, from back in February (from the initial detailed vgo blog > series): > > > "The details here may be revised, but today's go.mod files will be > understood by any future tooling. Please start tagging your packages with > release tags; add go.mod files if that makes sense for your project." > > And from the 1.11 release notes: > > > "Module support is considered experimental. Details are likely to > change in response to feedback from Go 1.11 users, and we have more tools > planned. Although the details of module support may change, projects that > convert to modules using Go 1.11 will continue to work with Go 1.12 and > later." > > I read that as saying that the exact behavior of modules may very well > change before modules become the default behavior, but that modules defined > and released under vgo or Go 1.11 will still be understood. > > In other words, feedback is still very valuable and will influence what > the behavior is in 1.12 and beyond. > > In my personal experience and from what I have observed, the core Go team > has been very willing not only to discuss changes to modules, but also to > make actual changes to how modules behave based on community feedback. > Here is one sample list of changes from the "Modules" wiki page, where > almost all of these changes were primarily driven by community feedback I > think: > > > https://github.com/golang/go/wiki/Modules#changes-since-the-initial-vgo-proposal > > In terms of the Go 1.11 behavior, there are still open questions, > including around what should the exact behavior be when modules are enabled > but you are outside of any particular module, or how to best support > simultaneously editing multiple modules, or what if any behavior the core > tooling might pick up from community tooling such as > https://github.com/rogpeppe/gohack, etc. In many cases, I believe some > of the currently open questions were purposefully left as open questions in > 1.11, including so that actual experience could better inform future > approaches. > > Filing module issues or commenting on existing issues is of course > valuable, but the core team has also expressed great interest in people > filing experience reports on real-world usages of modules. From the > experience reports wiki page ( > https://github.com/golang/go/wiki/ExperienceReports): > > "The best experience reports tell: (1) what you wanted to do, (2) what > you actually did, and (3) why that wasn’t great, illustrating those by real > concrete examples, ideally from production use. Please write these reports > about the problems most significant to you, post them on your own blog, or > on Medium, or as a Github Gist (use a .md extension for Markdown), or as a > publicly-readable Google doc, and then link them here." > > In any event, as a member of the community, I would certainly encourage > feedback from other members of the community... > > --thepudds > > On Friday, September 21, 2018 at 7:57:02 PM UTC-4, Scott Cotton wrote: >> >> Hi all, >> >> I for one would also consider the interface an improvement if as part of >> making modules work outside of a "main module" included making go test >> ./... work >> as before. Perhaps ./... could mean find each top level module in src/ >> and test. >> >> I am not sure what the modules implementors would prefer w.r.t. such >> feedback. On >> the one hand they need it and can't possibly envision how everyone uses >> the tooling, and >> have wisely called it preliminary. >> >> On the other, maybe it's not a bug as modules are defined; also I think >> they have obligated >> themselves to maintaining support for the current functionality, which >> some might not >> find fitting to the way they work. For example from golang.org/cmd/go: >> """ >> We intend to keep revising this support, while preserving compatibility, >> until it can be declared official (no longer preliminary), and then at a >> later point we may remove support for work in GOPATH and the old 'go get' >> command. >> """ >> >> >> This makes it unclear to me at least how to categorise or proceed with >> feedback like John's, >> where there is an unexpected error. >> >> I would like to suggest that a tendency towards flexibility in >> implementing the statement above from golang.org >> might allow a more informed basis on which to take modules out of >> preliminary status. But others >> may depend on or like modules behaviour like this. I have no way of >> knowing. >> >> Also, yes I agree the listing of the deleted go.mod looks like a bug to >> me as well. >> >> Best, >> Scott >> >> >> >> >> >> On Friday, 21 September 2018 21:41:39 UTC+2, 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.
