Re: [Administrivia] On ruby and contrib/

On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] 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