The package cannot be vendored with `vndr` (regression in #137)

[AkihiroSuda]

vndr omits the go-systemd package when github.com/coreos/go-systemd is specified in vendor.conf, due to the regression in #137.

vendor.conf:

github.com/containerd/cgroups 918ed86e29ccef2bf3f0c70d76405781afc3bdf5
github.com/coreos/go-systemd v22.0.0
...

vndr output:

...
2020/01/09 16:35:37 WARNING: package github.com/coreos/go-systemd is unused, consider removing it from vendor.conf

If github.com/coreos/go-systemd/v22 is specified in vendor.conf instead, vndr fails as follows:

2020/01/09 16:38:59 WARNING: package github.com/coreos/go-systemd/v22 is not root import, should be github.com/coreos/go-systemd

vndr version: LK4D4/vndr@d87a917

[AkihiroSuda]

cc @Zyqsempai @LK4D4

[thaJeztah]

Shouldn't those upstream packages use a /vX subdirectory?

[AkihiroSuda]

Seems they intentionally chose not to use subdir coreos/go-systemd#307 (comment)

[thaJeztah]

I'd like not to have to move directories around for each breaking change (i.e. /vX -> /vY)

Yeah; they'd still have to update import paths with each release though. I guess go mod is gonna be a pain whichever way.

Curious though; was it a deliberate choice to use both v1 and v5 of the godbus/dbus package in this repository? I see that this file did not move to v5;

cgroups/v2/utils.go

Line 31 in fe68974

"github.com/godbus/dbus"

Also wondering if moving (containerd) to go.mod (and using the vXX import paths) is a breaking change, thus would mean containerd will have to bump major version to v2+ because of that

[AkihiroSuda]

thus would mean containerd will have to bump major version to v2+ because of that

Kubernetes didn't bump major

[thaJeztah]

Does kubernetes actually use SemVer, or only "fake SemVer for the sake of go modules?" (as many packages)

[AkihiroSuda]

Fix for vndr: LK4D4/vndr#87

[thaJeztah]

Fix for vndr: LK4D4/vndr#87

🤗 LOL literally just now opened vndr in my IDE to see if I could fix it there 😂