Add go.mod and pin dependencies#810
Conversation
|
not a bad idea, but it fails travis CI |
|
@ashokponkumar could you rebase? |
rebased. |
| @@ -0,0 +1,241 @@ | |||
| cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= | |||
There was a problem hiding this comment.
this go.sum file does not even need to be checked in
There was a problem hiding this comment.
Its generally the practise to checkin go.sum too. But if we don't want for this repo, we can remove it. (Ex: https://github.com/kubernetes/kubernetes/blob/master/go.sum)
| @@ -0,0 +1,12 @@ | |||
| module github.com/opencontainers/image-spec | |||
There was a problem hiding this comment.
after some discussion on the call, I'm not sure that we want to have a single go.mod at the top level of the project, but instead to have a go.mod in any immediate subdirectory that contains golang source.
The reasoning behind this is: if say ./schema/ brings in a dependency that is wholly not needed if someone only needs to import ./specs-go/, importers need only fetch specs-go/go.mod related deps (which is likely always none).
We just did similar on the distribution-spec
There was a problem hiding this comment.
Sure. I have added for specs-go. Adding to schema to creates some ambiguous import issue.
go: finding module for package github.com/opencontainers/image-spec/specs-go/v1
go: found github.com/opencontainers/image-spec/specs-go/v1 in github.com/opencontainers/image-spec v1.0.1
github.com/opencontainers/image-spec/schema: ambiguous import: found package github.com/opencontainers/image-spec/schema in multiple modules:
github.com/opencontainers/image-spec/schema (/Users/ashokponkumar/go/src/github.com/ashokponkumar/image-spec/schema)
github.com/opencontainers/image-spec v1.0.1 (/Users/ashokponkumar/go/pkg/mod/github.com/opencontainers/image-spec@v1.0.1/schema)```
There was a problem hiding this comment.
oh dang. Just did some research on this, and it's a go modules mess ... and sounds like what @tianon mentioned during the image-spec grooming call with having to do special git tags also.
I found that the popular import github.com/ugorji/go/codec went through this when they brought in go modules.
ugorji/go#299
They ended up having to add circular referencing go.mod files, based on tag versions, and also to make multiple tags for each of the sub-directories as their own modules https://github.com/ugorji/go/tags
I'm now wondering if this is all worth it, or is it just simpler to keep the go.mod file at the topic level directory like you began with :-\
@opencontainers/image-spec-maintainers thoughts?
(p.s. i'm curious why the we didn't hit this in the distribution-spec?)
There was a problem hiding this comment.
The reason the issue is not there in distribution-spec is that, it has only one go module in the repo.
Signed-off-by: Ashok Pon Kumar <ashokponkumar@gmail.com>
Closes opencontainers#810 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
|
thank you @ashokponkumar for your PR! and congrats on your first commit! |
|
Thanks @vbatts for taking it through the process and getting it merged. |
Closes opencontainers#810 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Signed-off-by: Ashok Pon Kumar ashokponkumar@gmail.com