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

Re: use of third_party directory for libcompose



That's great, we'll help navigate the godep process (it can be tricky).

> On Jun 28, 2016, at 9:52 AM, Tomas Kral <tkral redhat com> wrote:
>
>> On Tue, Jun 28, 2016 at 5:32 PM, Clayton Coleman <ccoleman redhat com> wrote:
>> Mostly because I had to make extensive changes to use it the way we
>> needed (as a parsing library to get at the structs), and an
>> incompatibility with the yaml library used by Kube.  We mostly need it
>> to parse the files and resolve the env bindings.
>
> It makes sense. Thank you for quick response.
>
>>
>> At the time, it was the easiest way to make progress.  Properly
>> godeping is definitely desirable, just didn't have a timeline for it.
>
> I might help with that.
> When I was investigating this I was able to modify generate.go code to
> work with current master branch of libcompose.
> After little bit more testing I can send PR with my modifications.
>
>>
>>> On Jun 28, 2016, at 6:31 AM, Tomas Kral <tkral redhat com> wrote:
>>>
>>> Hi,
>>> I've been looking how docker-compose support is implemented in OpenShift Origin.
>>> And I have one question regarding use of libcompose:
>>>
>>> Why is libcompose in third_party directory, and it is not managed
>>> using godeps like other dependencies?
>>>
>>> I would like to state that I'm quite new to whole Go lang ecosystem,
>>> so this might be stupid question :-) But this is something that I
>>> wasn't able to figure out.
>>>
>>>
>>> --
>>> Tomas
>>>
>>> _______________________________________________
>>> 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]