[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift go client library



On 11 October 2016 at 17:23, Tomas Kral <tkral redhat com> wrote:
> On Tue, Oct 11, 2016 at 3:26 PM, Dan Mace <dmace redhat com> wrote:
>> On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein <agoldste redhat com> 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
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]