*: remove vendoring

[runcom]

Fix #527

specs-go acts as a package. No need to have vendoring in here as it
would just cause major pain to people using the specs Go library.

Signed-off-by: Antonio Murdaca runcom@redhat.com

[vbatts]

lets see. We just added it in #486
There is something nice about the posterity of having the precise source used for the spec provided in the release tarball. Though these compilation issues due to it being in the "vendor/" directory are troublesome.

[jonboulle]

Yeah. Honestly I'd rather just move the code from that repo in-tree here. Failing that, can we type alias, does that trick actually work?

…

On 25 January 2017 at 16:36, Vincent Batts ***@***.***> wrote: lets see. We just added it in #486 <#486> There is something nice about the posterity of having the precise source used for the spec provided in the release tarball. Though these compilation issues due to it being in the "vendor/" directory are troublesome. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#528 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACewN1SKvFL9O_gMl2Ed8daPhPLMQsNRks5rV2v9gaJpZM4LtiQ0> .

[runcom]

Yeah. Honestly I'd rather just move the code from that repo in-tree here.

this would be nice probably

[vbatts]

Or even just mv ./vendor/ ./_deps. It's part of this golang vendor experiment. The path resolution assumes long path available is the choice, just not having this stashed code in a directory named "vendor" would fix this issue

[jonboulle]

That doesn't solve the issue of vendored deps being used in exported interfaces Vincent Batts <notifications@github.com> schrieb am Mi., 25. Jan. 2017, 19:16:

…

Or even just mv ./vendor/ ./_deps. It's part of this golang vendor experiment. The path resolution assumes long path available is the choice, just not having this stashed code in a directory named "vendor" would fix this issue — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#528 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACewN10aqGynaJ6Rmv5ZO3Nuux-tnBvIks5rV5F9gaJpZM4LtiQ0> .

[stevvooe]

That doesn't solve the issue of vendored deps being used in exported
interfaces

Is this considered not best practice? Are we not supposed to vendored types in exported types?

[vbatts]

Current Idea is to move the ./vendor directory(s) under the packages that use remote repos.

[mtrmac]

That doesn't solve the issue of vendored deps being used in exported
interfaces

Is this considered not best practice? Are we not supposed to vendored types in exported types?

(referring to e.g. func Foo(param vendoredpkg.Type), where vendoredpkg is visible to consumers as GitHub.com/opencontainers/image-spec/vendor/foo/bar/vendoredpkg; importing a package with /vendor/ is prohibited by Go).

• It is impossible to even name the vendored types (e.g. if I want to declare a variable, or a helper function with a parameter, or a return value)
• It is also impossible to call constructors in the vendored packages.

Basically, exported vendored types are only usable as return values which are immediately consumed.

[vbatts]

as our repo is effectively only library, then this is a best option.
For packages that are main, they can vendor these sources in their package.

LGTM

This may need to be included in the RC4 (#537)

[stevvooe]

LGTM

I am generally fine with this approach. At some point, I'd like to stabilize the Go packages, but we'll just have to be flexible with future build problems.

[jonboulle]

Gah, no like this. Now we provide NO guidance for downstream consumers for what they should use? Go is a mess.

[cyphar]

I think that, while it is a massive hack, https://gopkg.in/ is the only sane way of handling these sorts of problems (though I don't know how they've handed the whole vendor "experiment").