cmd/go: compile net/http when GO15VENDOREXPERIMENT=0 #13961
Comments
|
/cc @rsc for opinions and/or ownership |
cespare
changed the title
|
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. |
|
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'd say yes.
Indeed. If they're putting code in there, I'd say they're promised nothing, environment-wise. |
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. |
|
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
|
|
CL https://golang.org/cl/18728 mentions this issue. |
In the Go 1.6 cycle, users should be able to disable vendoring (in case they use directories named
vendor) usingGO15VENDOREXPERIMENT=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.The text was updated successfully, but these errors were encountered: