why the image-spec has a vendor directory?

[runcom]

runtime-spec doesn't have it, it doesn't vendor anything at all. Right now, this is breaking code which uses the image-spec with stuff like:

oci/layout/oci_dest.go:142: cannot use digest (type "github.com/opencontainers/go-digest".Digest) as type "github.com/opencontainers/image-spec/vendor/github.com/opencontainers/go-digest".Digest in assignment

I understand this is how golang works, but image-spec isn't going to work as a package this way..

@vbatts can we get rid of that vendoring altogether?

[mtrmac]

Similar issue: distribution/distribution#2130 .

I’d prefer dropping the vendor directory, but if that were not acceptable, at least a type Digest digest.Digest somewhere in the non-vendor parts of the tree would make the type available for casts.

[stevvooe]

@mtrmac @runcom Do your vendoring tools not remove subvendoring?

[runcom]

@stevvooe we use vndr (used is docker projects as well). The point is not what we use. The point is that packages other than the "main" one shouldn't have a vendor folder at all to me.

[mtrmac]

@mtrmac @runcom Do your vendoring tools not remove subvendoring?

If a library expects all its consumers to remove its vendored dependencies, then presumably the library does not care which version of those dependencies are used when the library is used in a consumer; in that case the library might just as well not vendor the dependency at all.

(Or, well, perhaps the library expects all its consumers to remove its vendored dependencies, and then vendor exactly the same version into the consumer. That breaks down pretty much every time two different libraries want to use the same dependency, in a diamond dependency pattern, because they are quite unlikely to want to use exactly the same version.)

AFAICT, it’s easiest when library APIs are backward-compatible and never remove or redefine old symbols. If that doesn't happen, vending can mask only some failure cases.