Support Go Modules #2895
Support Go Modules #2895
Conversation
|
Please sign your commits following these rules: $ git clone -b "support_modules" git@github.com:SamWhited/swarmkit.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -fAmending updates the existing PR. You DO NOT need to open a new one. |
Codecov Report
@@ Coverage Diff @@
## master #2895 +/- ##
==========================================
+ Coverage 61.58% 63.78% +2.19%
==========================================
Files 139 3 -136
Lines 22616 439 -22177
==========================================
- Hits 13928 280 -13648
+ Misses 7207 107 -7100
+ Partials 1481 52 -1429 |
| package swarmkit | ||
|
|
||
| import ( | ||
| _ "github.com/stevvooe/protobuild" |
There was a problem hiding this comment.
There was a comment in the makefile about how the protobuild tool should be moved into vendor. This does that and allows us to pin to a specific version of the tool in go.mod (which also made the build easier since we didn't have to try and install this somewhere in the path).
| go 1.12 | ||
|
|
||
| require ( | ||
| code.cloudfoundry.org/clock v0.0.0-20180518195852-02e53af36e6c |
There was a problem hiding this comment.
Looks like this commit was now tagged as 1.0.0; cloudfoundry/clock@02e53af
There was a problem hiding this comment.
Sadly, go modules does not support this. I can leave a comment making it clear what commit it's using, but that's about it. If you want to verify, you can run go get code.cloudfoundry.org/clock@1.0.0 which will find the tag, but will write the commit to the mod file. Alternatively, edit the mod file to include the correct version (go mod edit -require=code.cloudfoundry.org/clock@1.0.0) and then run go mod tidy and it will rewrite it.
There was a problem hiding this comment.
I should also say that I'm hesitant to leave a comment, the next time we update those just get forgotten and end up being out of date.
There was a problem hiding this comment.
Filed cloudfoundry/clock#8
There was a problem hiding this comment.
It doesn't support it because it doesn't have a v as prefix? That should be a bug in go mod; SemVer does not require the v prefix; in fact, the prefix is invalid SemVer; there was a proposal for a SemVerTag standard (which required v for tags), but that was removed in SemVer 1.0; semver/semver#1 (comment)
from the SemVer specification; https://semver.org/#is-v123-a-semantic-version
Is “v1.2.3” a semantic version?
No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.
I see they had some discussion about this in 2015; golang/go#12302 (comment)
There was a problem hiding this comment.
Yes, sadly the v is deliberately required (amusingly, one of the reasons v was used is because Docker used it). I can't find the discussion right now, but I think only one was used because they didn't want to deal with the case where someone mixes versions and pins the same version to two different commits (eg. 1.0.0 and v1.0.0 on the next commit). Which do you pick? In the end, I believe they decided it was easier to just support a single standard and let the Go community normalize on that in the same way that gofmt isn't everybody's favorite format, but the consistency is worth it.
There was a problem hiding this comment.
ugh; ironic, because they "enforce" SemVer, but don't actually support valid SemVer 🤷♂
| github.com/beorn7/perks v0.0.0-20190414131216-e7f67b54abbe // indirect | ||
| github.com/cloudflare/cfssl v0.0.0-20180323000720-5d63dbd981b5 | ||
| github.com/coreos/etcd v3.3.12+incompatible | ||
| github.com/coreos/go-systemd v0.0.0-20180511133405-39ca1b05acc7 // indirect |
There was a problem hiding this comment.
This package tags releases, but they're not SemVer (https://github.com/coreos/go-systemd/releases); is there a way to show that this matches a tag and/or force go mod to use a tag?
There was a problem hiding this comment.
No :( see previous comment. We can manually tell it to use a tag when running go get, but that's about it.
| github.com/cloudflare/cfssl v0.0.0-20180323000720-5d63dbd981b5 | ||
| github.com/coreos/etcd v3.3.12+incompatible | ||
| github.com/coreos/go-systemd v0.0.0-20180511133405-39ca1b05acc7 // indirect | ||
| github.com/coreos/pkg v0.0.0-20160727233714-3ac0863d7acf // indirect |
There was a problem hiding this comment.
same for this one https://github.com/coreos/pkg/releases
Signed-off-by: Sam Whited <sam@samwhited.com>
|
This has been done in #3061 (thanks for kicking of the work @SamWhited - hope you're doing well!) |
Experiment with modules support.
Note that if you run
go mod vendorwith Go 1.13 the vendor validation will be broken because they've changed the vendoring / go.mod rules (again). Future PRs will need to use Go 1.12, or we can bump tests to run with Go 1.13 and require that everyone use that. Hopefully these rules will stabilize soon.