Re: [Administrivia] On ruby and contrib/

[Felipe Contreras <felipe.contreras@gmail.com>]

On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>>> <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi Greg,
>>>>
>>>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>>>
>>>>> As one of the people who helps maintain git packages in pkgsrc, my
>>>>> initial reaction is negative to adding a ruby dependency.
>>>>
>>>> My initial reaction, too. It was hard enough to get Perl included with Git
>>>> for Windows (because of that pesky Subversion dependency).
>>>>
>>>> As you can see from the commit history, I was the primary force behind
>>>> trying to get everything "core" in Git away from requiring scripting
>>>> languages (I think it is an awesome thing to provide APIs for as many
>>>> languages as possible, but a not-so-cool thing to use more than one
>>>> language in the core code). It does not seem that anybody picked up that
>>>> task when I left, though.
>>>
>>> Nobody seems to mention it yet. There's another reason behind the C
>>> rewrite effort: fork is costly on Windows. The C rewrite allows us to
>>> run with one process (most of the time). This applies for shell, perl
>>> and even ruby scripts because libgit.a is never meant to be used
>>> outside git.c context (unlike libgit2). In this regard, ruby is just
>>> as bad as currently supported non-C languages.
>>
>> Are you sure?
>
> I'm not saying you can't. I'm saying it's not meant to be used that
> way. Which means there may be problems lurking around.

Code is code. If something is not meant to be used in certain way, you fix it.

> You can write a ruby extension to access libgit.a, sure,

I'm not using libgit.a, I'm using the builtin commands. This is
exactly the same code you run when you type 'git foo'.

> but how many people on this
> list understand git design and limits _and_ ruby's good enough to spot
> the bugs?

Now you are changing the subject. Does that mean that you accept that
'fork' wouldn't be a problem when writing Ruby scripts?

As for the people that know Git and Ruby; they can learn. Didn't you
just said that you didn't see any problem with the community learning
a new language?

> If a bug is found and requires major restructuring in
> libgit.a, how are you sure it's worth the effort and does not
> destablize the rest of git?

There is no need to destabilize anything. I just showed you 100 lines
of code that are able to run git commands without forks, and without
changing anything in libgit.a.

> A better way to do it is linking against libgit2.

I would rather use what the rest of Git uses. It doesn't make any
sense fragment even more the code, and make Ruby scripts 2nd class
citizens along the way. Plus, any script that tries to use libgit2,
would certainly need more than 100 lines.

-- 
Felipe Contreras