Re: Python extension commands in git - request for policy change

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 25, 2012, 11:19 UTC
Message-ID: <CAMP44s1oRpm4QkhcbfAuxK8UTZnuSVfNhAQnmUd1xiwhwLEqGw@mail.gmail.com>
In-Reply-To: <20121125095356.GA22279@thyrsus.com>

On Sun, Nov 25, 2012 at 10:53 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

Show 8 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com>:
>> If your friends jump off a bridge, would you? Yes, using python has
>> served them well, but as opposed to what? Other scripting languages? I
>> don't think so.
>
> The competition that Python won was *precisely* against other scripting
> languages, notably shell and Perl.  Both used to be much more heavily
> used in system scripting than they are now.

Against shell and perl yes, not against the rest.

Show 5 quoted lines

>> What if my extension only supports python 2.7? Or what if my extension
>> wants to support 2.0?
>
> I propose that if 2.6 can't support it, then that should be considered
> grounds to reject it.

Seems sensible, but I don't know what "rejection" would actually mean. My "extensions" are on the way to the contrib area. Is the contrib area supposed to have different rules? I don't know.

Either way, making a script work on python 2.6 is probably easier than trying to "reject" it.

>> Yes, they should _if_ they know what version they need. In my
>> extensions I really have no idea.
>
> Then you shouldn't submit those extensions to be folded into core git.

Too late.

Show 9 quoted lines

>> > 3) We should be unconditionally be encouraging extensions to move
>> > from shell and Perl to Python.  This would be a clear net gain is
>> > portability and maintainability.
>>
>> NO! It's up to the developer to choose what language to use,
>
> I agree.  You seem to be raising a lot of straw men.  'Encouragement'
> does not equate to beating anyone who makes an unpopular choice over
> the head.

I don't see what this means in practical terms. People are going to write code in whatever language they want to write code in. How exactly are "we" going to "encourage" them not to do that is not entirely clear to me.

I don't think there's such a thing as "git leadership" that would be able to take these policy decisions, and if there was one, I don't think the evidence presented would be enough to weigh in either way.

> I am also not suggesting that the whole git core ought to be hoicked
> over to Python.  I was thinking mainly about extension subcommands,
> not what's in libgit now.

Subcommands are also probably more efficient in c. And lets remember that most people use git through the *official* subcommands.

Cheers.

-- 
Felipe Contreras