I fully agree with Aaron. Both are fine additions but they should be opt-in instead of opt-out. "We" (and myself) have Vet in the linting stage of all of our projects. We do not want to run a static analysis in the test stage. Also, until the dependency issue is fixed for all possible scenarios I do not see this enabled either. Wasting CPU time is OK-ish, but wasting developer time for hunting down caching-problems is definitely not good.
On Friday, December 8, 2017 at 6:28:47 PM UTC+1, Aaron Lefkowitz wrote: > > 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.
