Re: [Administrivia] On ruby and contrib/

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

On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:

> I however do not know how much extra burden it would place to add
> dependencies to platform folks, so obviously the safer approach is 1
> at least in the immediate future.  My understanding is that msysgit
> folks are already having trouble with Python, and we do not want to
> go route #2 at least for now.  Having to ship a variant of Git with
> NO_PYTHON is already bad enough.  And that is why the option 1 above
> does not list Python as a possible candidate.

This rests on the assumption that Ruby would be as difficult to
distribute as Python, which might not be the case.

> As the maintainer, I've been thinking about closing contrib/ area
> for new stuff, and shrinking existing ones, either by moving stuff
> that are only useful within the context of Git to main part of the
> tree (e.g. "contrib/workdir" may move to a new directory "addons/",
> some of remote-helpers in contrib/ may move to "remote-helpers/",
> etc.), and removing others from contrib/, for this reason.  Of
> course, interested folks can take the last version of the removed
> ones and continue improving them as standalone projects.

This does make sense, however, I do think some parts of Git might be
more maintainable if they have their own Makefile (e.g. bash
completion), where it's clear where they should be installed by
default.

Either way, the user might want to do 'install-all' or
'install-addons', to install all these things, and I think a good rule
of thumb is that if we don't want 'install-all' to install certain
script (eventually), then that script probably doesn't belong in
'contrib' (or anywhere in Git).

> The rest is just a personal opinion.
>
> If we were looking at a compelling and sizeable web application that
> depends on Rails, it is very likely that it would not make much
> sense to rewrite it in other languages only to avoid a new language
> dependency on Ruby.
>
> But "related" is "read and extract some info out of text files,
> spawn a 'blame' (or two) based on that info, read to collect further
> info and summarize", for which Ruby does not especially shine
> compared to Perl, which is the language we already depend on.
> Because of this, I am moderately reluctant to add Ruby dependency
> only for this script.  Unless I know people who regularly give us
> high quality reviews, and those who support various platforms, are
> fine with it, that is.
>
> In the shorter term (read: up to 2.0), I am inclined to vote that we
> should go route #1 (i.e. rewrite in Perl once the design settles).

That might make sense for the shorter term, but in longer term I see
Perl as declining in favor of other languages. It's only a matter of
time before Ruby surpasses Perl in popularity, and soon enough new
contributors to the Git project will have problems trying to improve
Git because parts of it are written in a language they are not
familiar with, and have trouble learning (isn't that already
happening?).

The Ruby vs. Python is another question altogether, I could go into
detail about why I think Ruby is a better choice, but my point right
now is that Perl is not a good choice for the future.

-- 
Felipe Contreras