x/net/lif, x/net/route: as long as std imports these packages, they can't import golang.org/x/sys/unix because of standard library policy

[dmitshur]

Updating to latest golang.org/x dependencies causes golang.org/x/sys/unix to be vendored into std, which goes against the policy set in #32102:

--- FAIL: TestScript (0.02s)
    --- FAIL: TestScript/prevent_sys_unix_import (1.68s)
        script_test.go:270: 
            # (2022-08-04T14:23:36Z)
            # Policy decision: we shouldn't vendor golang.org/x/sys/unix in std
            # See https://golang.org/issue/32102 (1.671s)

It's happening because the golang.org/x/net/lif package (vendored into std) has been updated to import and depend on golang.org/x/sys/unix in CL 413275 and CL 414994:

src $ go mod why 'golang.org/x/sys/unix'
# golang.org/x/sys/unix
net
golang.org/x/net/lif
golang.org/x/sys/unix

To make progress on #36905, I will likely need to send CLs to revert those golang.org/x/net/lif simplification CLs.

Package net seems to only use golang.org/x/net/lif in one function call interfaceAddrTable, so a path that can be investigated in the future is whether removing that dependency can be simpler overall.

CC @tklauser, @ianlancetaylor, @bcmills.

[dmitshur]

Next up:

$ go mod why 'golang.org/x/sys/unix'
# golang.org/x/sys/unix
net
golang.org/x/net/route
golang.org/x/sys/unix

Reverting CL 419180 is enough to resolve this and avoid x/sys/unix getting vendored into std.

[gopherbot]

Change https://go.dev/cl/421334 mentions this issue: all: update vendored golang.org/x dependencies for Go 1.20 development

[ianlancetaylor]

It may be possible to use syscall rather than x/sys/unix for these constants.

[gopherbot]

Change https://go.dev/cl/421419 mentions this issue: lif: import syscall rather than golang.org/x/sys/unix

[gopherbot]

Change https://go.dev/cl/421425 mentions this issue: route: import syscall rather than golang.org/x/sys/unix

[dmitshur]

Thanks Ian for finding a resolution to this issue that's better than reverting those earlier x/net CLs. I'm glad I left x/net out of CL 421334 to create an opportunity to take time to think about this (without the pressure of #53812).

I've sent CL 421461 to vendor the latest x/net in the main repo, and will close this now because I don't think there's anything left to do.

I've considered adding a test to x/net (also suggested by @prattmic), but such a test would either need to hard-code which x/net packages are vendored in std, or extract that dynamically somehow which is probably better suited for #48523. If this happens more often we can revisit it. (If someone has an idea for a better test, please feel free to file an issue.)