Remove dependencies on k8s.io/apimachinery

[mtrmac]

Per #207 (comment) , depending on the latest versions of k8s.io makes this code very difficult to use in openshift/origin. So, drop dependencies on k8s.io/apimachinery/pkg/util/{error,net} by inlining or copying the necessary parts.

(This leaves k8s.io/pkg/util/homedir, which seems not to cause issues right now.)

[runcom]

👍

[mtrmac]

… broken again, by kubernetes/kubernetes@335ef74 .

[erikh]

Sorry to distract. I was working on a vendoring patch to help solve this problem in a few spots (github.com/Microsoft has a few gems too if you guys have been watching the things I tagged you on). I think (open)containers needs to settle on a global vendoring solution. This "rsync into dir" does not scale for the reasons we're seeing now. A well defined, centralized dep list would go a long way towards stability in the projects (due to matched deps) and also make it easier to isolate problems. However, I lack the political clout to carry out such an action. If this is a desired thing I can put together the patches across openshift/opencontainers/containers to sync this all up to standardized versions and maybe settle on `hack/vendor.sh` or godep to keep the repositories small since they only import parts of repos. I talked to alex on the vndr project and he told me vndr cannot do subsets of repositories; making it so that we have to import all of docker/docker for docker/pkg/term. Anyways, I can open an issue/set of issues if you think this is a good idea.

…

On Mon, Jan 23, 2017 at 10:16 AM, Miloslav Trmač ***@***.***> wrote: … broken again, by ***@***.*** <kubernetes/kubernetes@335ef74> . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#225 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABJ66bEhwFqISn3565i-cG-VAhnkJFRks5rVO5tgaJpZM4LrXEc> .

[mtrmac]

A well defined, centralized dep list would go a long way towards stability in the projects (due to matched deps) and also make it easier to isolate problems.

While I would certainly like not having to care, the trouble is that we don’t want to freeze the versions forever; if this did succeed and we had 20 projects using a centralized dependency list, it would in turn be politically very difficult to change the list in the future. The various upstreams do add quite a few bug fixes, not only breaking changes, and we do want to get those bug fixes with little hassle :)

Sharing a dependency list between skopeo and containers/image does sound very attractive, but with that we would probably have not encountered the recent breaking changes for a good few months, if not years—which would not make the porting work smaller, it would only aggregate it in time to a single week (and probably a time when it would be much more urgent than now, when we are haunted only by our own CI).

I talked to alex on the vndr project and he told me vndr cannot do subsets of repositories; making it so that we have to import all of docker/docker for docker/pkg/term.

That may be misleading: with vndr, one has to record an entire repository in vendor.conf, and perhaps all of that repository is pulled into a temporary directory, but the resulting vendor/github.com/docker directory is pruned to only contain the actually used subpackages.

[erikh]

Hmm. @LK4D4 told me otherwise, perhaps he's willing to comment?

…

On Mon, Jan 23, 2017 at 10:38 AM, Miloslav Trmač ***@***.***> wrote: A well defined, centralized dep list would go a long way towards stability in the projects (due to matched deps) and also make it easier to isolate problems. While I would certainly like not having to care, the trouble is that we don’t want to freeze the versions *forever*; if this did succeed and we had 20 projects using a centralized dependency list, it would in turn be politically very difficult to change the list in the future. The various upstreams do add quite a few bug fixes, not only breaking changes, and we do want to get those bug fixes with little hassle :) Sharing a dependency list between skopeo and containers/image does sound very attractive, but with that we would probably have not encountered the recent breaking changes for a good few months, if not years—which would *not* make the porting work smaller, it would only aggregate it in time to a single week (and probably a time when it would be much more urgent than now, when we are haunted only by our own CI). I talked to alex on the vndr project and he told me vndr cannot do subsets of repositories; making it so that we have to import all of docker/docker for docker/pkg/term. That may be misleading: with vndr, one has to record an *entire* repository in vendor.conf, and perhaps all of that repository is pulled into a temporary directory, but the resulting vendor/github.com/docker directory is pruned to only contain the actually used subpackages. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#225 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABJ6whoyLlex9kv2dwtaSm3BjwejaIZks5rVPPDgaJpZM4LrXEc> .

[erikh]

Either way, the vendoring tool doesn't concern me much; the centralized list does. I agree the list would be hard to change; that is a huge problem to solve. I'll think about this and start another ticket when I have actual plans. :)

…

On Mon, Jan 23, 2017 at 10:44 AM, Erik Hollensbe ***@***.***> wrote: Hmm. @LK4D4 told me otherwise, perhaps he's willing to comment? On Mon, Jan 23, 2017 at 10:38 AM, Miloslav Trmač ***@***.*** > wrote: > A well defined, centralized dep list would go a long way towards > stability in the projects (due to matched deps) and also make it easier to > isolate problems. > > While I would certainly like not having to care, the trouble is that we > don’t want to freeze the versions *forever*; if this did succeed and we > had 20 projects using a centralized dependency list, it would in turn be > politically very difficult to change the list in the future. The various > upstreams do add quite a few bug fixes, not only breaking changes, and we > do want to get those bug fixes with little hassle :) > > Sharing a dependency list between skopeo and containers/image does sound > very attractive, but with that we would probably have not encountered the > recent breaking changes for a good few months, if not years—which would > *not* make the porting work smaller, it would only aggregate it in time > to a single week (and probably a time when it would be much more urgent > than now, when we are haunted only by our own CI). > > I talked to alex on the vndr project and he told me vndr cannot do > subsets of repositories; making it so that we have to import all of > docker/docker for docker/pkg/term. > > That may be misleading: with vndr, one has to record an *entire* > repository in vendor.conf, and perhaps all of that repository is pulled > into a temporary directory, but the resulting vendor/github.com/docker > directory is pruned to only contain the actually used subpackages. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#225 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AABJ6whoyLlex9kv2dwtaSm3BjwejaIZks5rVPPDgaJpZM4LrXEc> > . >

[LK4D4]

@erikh everything unused is pruned, but what is used has the same version within project, so all deps which starts from i.e. github.com/coreos/etcd will have same version.

[erikh]

gotcha; misunderstood. thanks alex. vndr should work fine, then! :)

…

On Mon, Jan 23, 2017 at 10:49 AM, Alexander Morozov < ***@***.***> wrote: @erikh <https://github.com/erikh> everything unused is pruned, but what is used has the same version within project, so all deps which starts from i.e. github.com/coreos/etcd will have same version. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#225 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABJ6yvLPBglosI0d_VTJ2GfC6a9-55Tks5rVPYvgaJpZM4LrXEc> .

[mtrmac]

Updated to also handle the k8s.io/kubernetes/pkg/util/homedir move. Though, that still doesn’t pass tests — I guess we will, in the end, have to end up with a single PR combining this and #223 .

[runcom]

this has been included in #223