Add support for Go Modules

[odinuge]

This removes vndr, and swiches to native Go Modules instead. All modules
are kept on the old version.

Keeps the vendor/ dir, so everything is backwards compatible.

This is more or less only go mod init

This would make it way easier for other projects using runc as dependency to keep track of the dependencies (and their version) that runc require.

It would be very nice to get this in before the v1.0.0 release!

[vrothberg]

Just a drive-by-comment (I am no maintainer). To make sure that the code and the ./vendor directory are in sync, we are using the following checks in the github.com/containers projects:

Makefile target

vendor:
	export GO111MODULE=on \
		$(GO) mod tidy && \
		$(GO) mod vendor && \
                $(GO) mod verify

Shell script tree_status.sh

Checks if the git tree has changed and prints a report.

#!/usr/bin/env bash
set -e

STATUS=$(git status --porcelain)
if [[ -z $STATUS ]]
then
	echo "tree is clean"
else
	echo "tree is dirty, please commit all changes"
	echo ""
	echo "$STATUS"
	exit 1
fi

CI (e.g., Travis)

Both are called in a CI job (make vendor && ./hack/tree_status.sh) to avoid inconsistencies from being committed.

[odinuge]

Hi @vrothberg! Thanks for the tips! k8s use the same too, but with a bit more hack-files. 😄

Added a simple check in 4f6014b now.

[thaJeztah]

similar discussion about validation in distribution/distribution#2941 (comment) (haven't checked if one has advantages over the other)

[vrothberg]

similar discussion about validation in docker/distribution#2941 (comment) (haven't checked if one has advantages over the other)

Awesome!

[vrothberg]

Hi @vrothberg! Thanks for the tips! k8s use the same too, but with a bit more hack-files. smile

Added a simple check in 4f6014b now.

LGTM, thanks!

[AkihiroSuda]

needs rebase

[nathanjsweet]

@vrothberg @odinuge do you need help to get this going? Definitely bother the devs on the slack channel to get this across the finish line. To any of the OCI devs: it's harder to contribute to, use, etc this repository without go modules.

[odinuge]

Thanks for the interest @nathanjsweet!

do you need help to get this going?
I think this should be good to go now (tests fail because of some problems installing postgres in CI), but I am absolutely open for suggestions. I have stopped rebasing the PR when conflicts occur in await for some interest from the contributors/reviewers from OCI. Hopefully some of them will look at it, so we can get go modules into the project.

Definitely bother the devs on the slack channel to get this across the finish line. To any of the OCI devs: it's harder to contribute to, use, etc this repository without go modules.

Agree! Have been using this in several projects myself, including k8s, and go modules (and a new release) will help the developer experience a lot!

[odinuge]

I also think #2029 is kinda important, and that PR should be merged before this one.

[odinuge]

ping @mrunalp

[saschagrunert]

@odinuge can you please rebase on top of the latest master branch? Then I would give this one a review if you don't mind. :)

[AkihiroSuda]

this should be put to the validate target?

[odinuge]

Yes! Thanks for catching it. Updated the PR now.

[hqhq]

LGTM

Use go modules makes sence to me, but I'm not sure why we are not using it in the first place, I think more maintainers should be aware of this change before merge.
@crosbymichael @mrunalp @cyphar

[h-vetinari]

@hqhq: [...] but I'm not sure why we are not using it in the first place [...]

Go modules became mature with Go 1.13 (released Sept '19), and this PR has been open since June 19. Together with the usual turnaround time for reviews here, that already seems like more than enough explanation to me... 😅

[hqhq]

@hqhq: [...] but I'm not sure why we are not using it in the first place [...]

Go modules became mature with Go 1.13 (released Sept '19), and this PR has been open since June 19. Together with the usual turnaround time for reviews here, that already seems like more than enough explanation to me... 😅

I see, thanks for explain. BTW does this mean we are not able to build runc without go 1.13 or newer?

[odinuge]

I see, thanks for explain. BTW does this mean we are not able to build runc without go 1.13 or newer?

We still keep the vendor/ directory with all the dependencies, so it will still work the same for pre go 1.13.

[h-vetinari]

Another conflict has arisen, unfortunately (due to merging #2222).

[odinuge]

Another conflict has arisen, unfortunately (due to merging #2222).

Ahh. Updated the PR now.

Since #2222 started building with go 1.14, and require it to pass, I switched back to running the vendoring in 1.14. If we vendor with go 1.13, go build will fail on go 1.14, making the tests fil.

[AkihiroSuda]

LGTM

[AkihiroSuda]

ping @opencontainers/runc-maintainers PTAL

[AkihiroSuda]

I'll merge this on Wednesday unless there are any objections

[cyphar]

LGTM. I do have some hesitation about some of the administrative aspects of Go modules (I've had issues with updating individual dependencies before, as well as problems with go mod vendor stripping out some source files that Debian needed) but we should still switch.