[go-nuts] Re: Go += Package Versioning
Hi Russ, I had a question about this: > We expect that most developers will prefer to follow the usual “major branch” convention, in which different major versions live in different branches. In this case, the root directory in a v2 branch would have a go.mod indicating v2, like this: It seems like there's subdirectories and this major branch convention that are both supported by vgo. In my anecdotal experience no repositories follow this convention in Go or other languages (can't actually think of a single one other than the ones forced to by gopkg.in which seems relatively unused these days). Master branch is whatever latest is and has v2.3.4 tags in it's history. Tags exist to separate everything (not just minor versions). If it's necessary to patch an old version, a branch is temporarily created off the last v1 tag, commits pushed, a new tag pushed, and the branch summarily deleted. There is no branch for versions, it's just current master/dev/feature branches + version tags. Having said that, I've tested the above described workflow with vgo (just having tags that say v2.0.0, v2.0.1 and no branches) and it does seem to work (though as an aside it is pretty confusing/annoying to have to change the require statement to say both /v2 as well as v2.0.0 when you upgrade the dependency in go.mod, not sure why that's required). So my question is: Although this works now, is it intended? As it doesn't seem as thoroughly described as the other two workflows in the blog, and I want to ensure that working without a v2/v3... branch is not accidental functionality that will disappear since as I explained above I've never seen this (or the other) described workflow in the post to be massively adopted by anyone (especially outside the Go community). Of course my argument is coming down to preference and anecdotes, so I'd be willing to do some repo-scraping to prove this across all languages if needed. So far I've really liked the proposal posts and am generally on board with the changes, will continue to follow along and play with vgo. Thanks for all your efforts. Aaron On Tuesday, February 20, 2018 at 9:20:54 AM UTC-8, Russ Cox wrote: > > Hi everyone, > > I have a new blog post you might be interested in. > https://research.swtch.com/vgo. > > I'll try to watch this thread to answer any questions. > > Best, > Russ > > > > -- 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.
Re: [go-nuts] Why so many opt-out changes to test runs in 1.10?
I agree on the getting the experience right for Go users piece and I think that we both see our views as in line with that theory. I think having less surprising, less gotchas and less defaults-gone-wrong behavior is better than enabling things that will get in their way and cost them development time. Remember the old adage that there are two hard things in programming, one of which is cache invalidation. I don't think we can get this correct. And so I stand by my point that this as a default will cause more harm than good. By the time a user has a sizable enough project (or dependencies) where test caching makes sense to use, it's reasonable to expect that they are no longer a beginner and that they can learn to use the flag if required to save themselves some test-run time. The other good thing about this, is we can easily change the default later to on once we figure out how good the feature is. In addition to that I think our viewpoints on test caching are different because our use cases of Go are different. I come upon this feature not as someone who deals with large berths of unchanging Go packages all the time (Go and it's standard library, presumably like yourself), but relatively small packages that interact with databases. In my use case I don't want my tests cached on my primary project as my test bottleneck is not the Go code that would be cached, but the database interaction that cannot be cached (because of the lack of invalidation at this layer). I understand you'd like me to try it, but if there's a provable theoretical problem with it, isn't it practical to address it, and isn't switching the default a reasonable way to address that? In the end I still feel strongly against the inclusion of test caching by default, and think it will bring pain to those who are not specifically asking for the feature whom are knowledgeable and who can turn it on when necessary anyway. On the go vet issue I'm actually a bit indifferent and no longer wish to pursue it's exclusion as a default simply because I don't care about this one enough. But I still think you should think on the arguments I've made here because it's a very inconsistent position to have taken. To glob on to go test's responsibilities but at the same time rejecting the idea that these same issues discovered by go vet cause major problems in normally compiled code is odd. The major problem with that stance of course is allowing one and disallowing the other for the same crimes. I've made some additional comments inline. Thanks for taking the time to respond. I've made all my points and don't want to waste your time with another response, so I will try these features and report the cache invalidation issue with a real use case and real code to show why it's a problem. Thanks very much for Go 1.10 and each release before it, I really enjoy the language. Aaron On Friday, December 8, 2017 at 11:21:37 AM UTC-8, Russ Cox wrote: > > First, a general point. > > We care very much about getting the default experience right for Go users. > These features are opt-in because we believe in both cases that "on" is the > right default, that developers will be more productive with these on by > default than having to know to opt in. > > - You should also not have to ask for "go test" to point out certainly > erroneous code instead of forcing you to find that code by debugging a test > failure. > > This conflates the idea of testing the code by running the tests you've created, with making sure the code is clean and correct. But this just suggests even further that if there are such "certainly erroneous" pieces of code, that the compiler should be catching it. If it is necessary for the program to run correctly, then it should not be a valid program, the inclusion of this feature as a default even demonstrates the need for it. > - You should not have to ask for "go test ./...; modify a few source > files; go test ./..." to do the right thing and only rerun the test > binaries affected by your changes. > > Doing the right thing and only rerunning the test binaries affected is not always the right thing, just sometimes, cache invalidation as noted above. > A new Go programmer who doesn't know these features exist should get the > benefit of these from day 1, without having to learn to set extra > configuration (which doesn't actually exist) or type extra arguments on > every go test command. Of course, turning them on by default means they > have to be right, and we're very sensitive to that. If you find concrete > examples where automatic vet or automatic test caching is causing you pain, > please file issues so that we can look to see if the defaults need further > adjustment. But please give them a chance first, actually try them, and > then report concrete problems, not hypotheticals based on simply reading > the release notes. > > Now a few specifics. > > For test caching: > > > Or
[go-nuts] Why so many opt-out changes to test runs in 1.10?
There's two features that are in Go 1.10 that are opt-out new defaults. I sincerely apologize for not being active enough to spot them before now. > The go test command now caches test results: if the test executable and command line match a previous run and the files and environment variables consulted by that run have not changed either, go test will print the previous test output, replacing the elapsed time with the string “(cached).” Test caching applies only to successful test results; only to go test commands with an explicit list of packages; and only to command lines using a subset of the -cpu, -list, -parallel, -run, -short, and -v test flags. The idiomatic way to bypass test caching is to use -count=1. There was some discussion on the Github issue that performance is the key concern (as it usually is when caching comes into play): https://github.com/golang/go/issues/11193 However on a follow-up discussion it appears that it's actually fairly impossible to be able to nail down the dependencies properly: https://github.com/golang/go/issues/22593 So the question would be why is this being introduced as an opt-out feature, where it will cause many problems until people realize that their test runs are being cached and disable it, which will lead to a "remember to turn this off, it causes problems" feature, which would mean the default is wrong. Why not do the easy fix here? There are people with problems in this area because their tests don't need to be re-run and it costs them significant amounts of time, why can't this simply be a -cache flag, not only is this much more intuitive than -count=1 to disable caching in general, but it preserves the behavior that: In most circumstances you will probably just want your tests to run, even if they were successful the last time, because something has changed; env, testdata, databases, external golden files, etc. Or maybe you are trying to debug a flaky test (up-enter enough times to get the intermittent error back now requires a -count=1). Let me be clear: This feature is amazing, and I want it. But I do think the default is wrong. > The go test command now automatically runs go vet on the package being tested, to identify significant problems before running the test. Any such problems are treated like build errors and prevent execution of the test. Only a high-confidence subset of the available go vet checks are enabled for this automatic check. To disable the running of go vet, use go test -vet=off. This is another opt-out change, why shouldn't it be an opt-in change? Tools can easily be built around this to ensure that when a particular project runs its tests it runs go vet first, this is trivial. You could argue that the way this was implemented (being close to the toolchain) makes it favorable to that solution because it's being run when there's cycles to spare (during link) and therefore the performance impact should be negligible. But then why just go vet? Why a subset of its checks? Why not golint? If it's going to prevent me from running my tests and I have to disable it in order to run these tests (despite being a valid Go program), why are they not compiler errors? In this particular issue I think it's more about surprising behavior than good defaults. It's surprising to me that go vet would prevent me from running a test. If I don't run it now, and so it doesn't prevent me from running tests, why should it in the future? It's surprising to me that effectively a "linting tool" is being run automatically when I run tests. It's surprising that when I compile a binary these same tests are not being run, and do not prevent me from compiling the binary, but specifically running tests, why is this? It's surprising to me that if I already run the go vet check before tests in my project, I'm actually running it twice now (in all projects that were savvy enough to already be doing this). It's also surprising that it's been implemented at such a low level (directly in the toolchain) when it's effectively just calling two commands in succession. Is there some strong reason to have it in the toolchain which I'm not seeing? Is there a good reason why it's on by default? Maybe the correct answer is to have go test -vet=on, where off is the default? Just hoping to generate some discussion on the inclusion of these as defaults. I think they're fine features, but they're certainly not for everyone, and I'm worried that the defaults might actually be much more harmful than good (more in the test cache sense than in the vet sense). Aaron -- 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.
