cmd/go: should we reuse GOMODCACHE in TestScript?

[mvdan]

When a txt script file is run as a subtest, we share the host's GOCACHE by default, presumably to allow reusing the build cache and speeding up go build commands inside each test:

                "GOCACHE=" + testGOCACHE,

You can verify this easily:

        > exec env
        [stdout]
        [...]
        GOCACHE=/home/mvdan/.cache/go-build

Should we do the same with the new GOMODCACHE Go environment variable? That would let the tests share the host's module download cache.

The upside is that, for most tests, we would download and copy fewer files, even if it's just the ones in testdata/mod/.

A potential downside is that if a test relies on actual downloads happening, they'd have to unset GOMODCACHE to use an empty module download cache.

Is this worth it? Opening an issue for discussion. /cc @bcmills @jayconrod @matloob

[bcmills]

Should we do the same with the new GOMODCACHE Go environment variable? That would let the tests share the host's module download cache.

The cmd/go tests use a local proxy, which we don't want to pollute the user's GOMODCACHE.

It would be possible, perhaps, to use a separate GOMODCACHE shared among the tests, except for a handful of tests that specifically check for caching behavior. (We didn't share the GOMODCACHE among tests initially in part due to #26794, which has long since been fixed.)

[jayconrod]

I don't think there would be much benefit to doing this. Tests that run in -short mode don't go out to the network and just download small files from the test proxy. That's true for the majority of long tests, too. I don't think there would be much gain in test speed.

There are a number of tests that verify whether something is present in the module cache. If we used the host's module cache, those tests would need to be updated to set GOMODCACHE explicitly.

Another issue is that we sometimes change the content of modules in the test proxy. We run a test checksum database that keeps up with those changes, but we wouldn't automatically re-fetch a file in the module cache that's out of date.

[mvdan]

Fair enough, I agree this is probably not worth it. I only thought of raising an issue because, since it's a new env var separate from GOPATH, it made the possibility easier than before.