Vendor dependencies with vndr #231
Conversation
Signed-off-by: Erik Hollensbe <github@hollensbe.org>
Signed-off-by: Erik Hollensbe <github@hollensbe.org>
Note the Microsoft/hcsshim package is a branch of erikh/hcsshim right now. This allows us to compile, because hcsshim does not have appropriate build tags. Signed-off-by: Erik Hollensbe <github@hollensbe.org>
|
Thanks for the PR. Recently we’ve run into very serious issues trying to use libraries which vendor their dependencies: distribution/distribution#2130 and opencontainers/image-spec#527 ; basically the vendored dependencies are not possible to use from callers of the library, without callers of the library using their own vendoring tool which strips the vendored dependencies… and then we might just as well not ship the vendored copies at all because we are again not in control of the versions of the dependencies. I do agree that this January, when containers/image has been broken by dependencies changing the API about half of the time, has been very painful, but it's not clear to me that this is noticeably better. (Also, in principle, we do want to be able to use the latest versions, or at least very recent versions, of the dependencies, most of the time; vendoring them would make it too easy to freeze very old versions without noticing. But that could, I suppose, be handled with some process change.) @runcom ? |
|
This is why I'm advocating for the monorepo that's shared amongst ALL
`containers/` projects. Dependencies from other libraries will be easier to
control and prevent conflict.
…On Tue, Jan 31, 2017 at 11:15 AM, Miloslav Trmač ***@***.***> wrote:
Thanks for the PR.
Recently we’ve run into very serious issues trying to use libraries which
vendor their dependencies: distribution/distribution#2130
<distribution/distribution#2130> and
opencontainers/image-spec#527
<opencontainers/image-spec#527> ; basically the
vendored dependencies are not possible to use from callers of the library,
without callers of the library using their own vendoring tool which strips
the vendored dependencies… and then we might just as well not ship the
vendored copies at all because we are again not in control of the versions
of the dependencies.
I do agree that this January, when containers/image has been broken by
dependencies changing the API about half of the time, has been very
painful, but it's not clear to me that this is noticeably better.
(Also, in principle, we do want to be able to use the latest versions, or
at least very recent versions, of the dependencies, most of the time;
vendoring them would make it too easy to freeze very old versions without
noticing. But that could, I suppose, be handled with some process change.)
@runcom <https://github.com/runcom> ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#231 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABJ6854-zaTdNuHapwdAZQ_7fZf2Fq7ks5rX4hrgaJpZM4LyTM7>
.
|
I don’t know, that could make sense (as a git submodule?), though it’s non-obvious that the coordination would work well. Somebody will always want to stay behind because they don’t have time now, and somebody will always want to push ahead for a new nifty feature. But even if that monorepo / submodule did exist, the above failure cases still suggest that containers/image should not just be shipping with a |
|
ok. I'm gonna close this then. You're right, this probably won't fly. |
This adds vendored dependencies. It also adjusts the tests to avoid the vendor dir.
As mentioned in containers/storage#24 I think this
would best be implemented eventually as vendor being a separate monorepo that
could share deps with both projects, while reducing repo churn. Maybe skopeo
too.
I started running into problems with some build tags so I imported a version of
hcsshim which has explicit build tags. You can see the appropriate ticket here:
microsoft/hcsshim#106
The fork is mine at erikh/hcsshim and it's a fork off master, should be good.
Please let me know if anything should change.