cmd/go: compile net/http when GO15VENDOREXPERIMENT=0

[cespare]

In the Go 1.6 cycle, users should be able to disable vendoring (in case they use directories named vendor) using GO15VENDOREXPERIMENT=0. This mostly works, but if the user imports net/http, it will not compile because net/http uses the new vendoring mechanism for http2.

See https://groups.google.com/d/msg/golang-dev/DJNCzxcLvgE/UW15IK6rEwAJ.

@bradfitz suggests that the fix is for the go tool to force-enable vendoring for the standard library even when GO15VENDOREXPERIMENT=0.

[bradfitz]

/cc @rsc for opinions and/or ownership

[rsc]

Is the standard library defined as code in $GOROOT? Sometimes people put other code there, but I guess we can force them into it too.

[rsc]

Actually, it's just one package. Can we have the bundle process just rewrite "golang.org/..." to "internal/golang.org/..." and mv vendor internal for one cycle?

[bradfitz]

Is the standard library defined as code in $GOROOT?

I'd say yes.

Sometimes people put other code there, but I guess we can force them into it too.

Indeed. If they're putting code in there, I'd say they're promised nothing, environment-wise.

[bradfitz]

Actually, it's just one package. Can we have the bundle process just
rewrite "golang.org/..." to "internal/golang.org/..." and mv vendor internal for one cycle?

I already fear Go 1.6.x branch maintenance once tip opens. This would be just one more headache to maintain that difference (in either cmd/bundle or my wrapper scripts around it).

I could if that's easiest, but it's only short-term easy. I'd prefer we fix this in cmd/go for this cycle.

[rsc]

Brad, I don't understand the point about Go 1.6.x. The only difference in the bundle output should be a single import path line. Or are you worried that Git won't know that the files moved and it will make cherry-picking CLs harder? I am not too worried about that, since I expect we will backport only critical http2 fixes to Go 1.6.x. I'd still like to just edit the bundle output. Note that at the start of the Go 1.7 cycle we can mv internal vendor again and undo the import change. OR if it would make things easier that could wait until the end of the 1.7 cycle. But this seems like a http2-specific issue, for being a (too) early adopter of the vendor directory. People do put code in $GOROOT and I don't want to make core changes to the logic in cmd/go in this case when we can make a 1-line change elsewhere. Russ

[gopherbot]

CL https://golang.org/cl/18728 mentions this issue.