Once it settles, yes. > On Oct 11, 2016, at 9:34 AM, Jimmi Dyson <[email protected]> wrote: > >> On 11 October 2016 at 17:23, Tomas Kral <[email protected]> wrote: >>> On Tue, Oct 11, 2016 at 3:26 PM, Dan Mace <[email protected]> wrote: >>>> On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein <[email protected]> >>>> wrote: >>>> >>>> We don't currently have a standalone go client library. Your best bet, for >>>> now, is to use Godeps to vendor in the same versions of dependencies that >>>> OpenShift currently uses. >>>> >>>> Andy >>> >>> >>> The way we handle this for various OpenShift Online components (which use >>> not only the client libraries but also other supporting data structures, >>> controller framework pieces, etc) is to use godep to restore origin’s >>> dependency tree into GOPATH and then vendor things back into our own >>> project. It’s pretty involved, but the overall steps are: >>> >>> 0. Using a clean GOPATH… >>> 1. Clone origin to $GOPATH/src/github.com/openshift/origin >>> 2. Clone kubernetes to $GOPATH/src/k8s.io/kubernetes >>> 3. Add and fetch a kubernetes Git remote at >>> https://github.com/openshift/kubernetes >>> 4. Use the origin `hack/move-upstream.sh` script to apply patches that >>> Origin carries to its various dependencies >>> 5. Use the origin `hack/godep-restore.sh` script to reconstitute all of >>> Origin’s dependencies within GOPATH >>> 6. Update any packages within GOPATH whose versions we want to override from >>> Origin >>> 7. Use `godep save ./…` in our own package within GOPATH to vendor our >>> dependencies from GOPATH >> >> This is really far from ideal :-( >> It forces me to use other libs that are forked by OpenShift, like >> github.com/openshift/glog :-( >> I have to manage my own godep-restore.sh for my project :( > > We use https://glide.sh/ for vendor management which works great with > forks - using godep was such a pita for the many forked repos that > openshift requires. > > I believe there are plans upstream to switch from godep to glide so > assume openshift will do the same in future? > >> >>> >>> Obviously this is far from ideal, but works and ensures our code is >>> compatible with a specific of origin and all its transitive dependencies. >>> There are some finer details omitted here (especially around >>> `hack/move-upstream.sh`). Feel free to reach out if I can provide further >>> clarifications. Good luck! >>> >>> —Dan >>> >>> >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
