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

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

 



On 25 November 2012 03:15, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote:
> CCing msysgit. I vaguely remember they had problems with building
> Python on Windows. I don't know if it's still an issue.
>
> On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond <esr@xxxxxxxxxxx> wrote:
>> git presently contains one Python extension command, Pete Wycoff's p4
>> importer.  If my git-weave code is merged it will acquire another.
>> I think we can expect more submissions of Python extensions in the
>> future, for two good reasons:
>>
>> 1. Python has a much richer type ontology than shell; there are many
>> things this makes relatively easy that are quite painful in shell.
>>
>> 2. While Perl shares advantage #1, compared to Python it's a
>> maintainability mess - much more difficult to read 6 months later.
>>
>> On the other hand,
>>
>> 3. Attitudes in the git dev group seem to be influenced by a
>> perception that up-to-date Python versions are not as reliably present
>> on our target platforms as Perl is.
>>
>> 4. Python has the disadvantage that comes with robust growth; you have
>> to specify "version x.y or later" as a dependency, mainly because new
>> modules keep getting getting folded into the stock Python environment.
>
> These may apply to other languages as well. Where do we draw a line?
>
>
>> Previous conversation on the list suggests that there has been a tacit
>> policy of managing these problems by (a) discouraging (though not entirely
>> forbidding) Python extensions, and (b) requiring extension submitters to
>> document some dependency on language version.
>>
>> I think this is suboptimal.  By not forbidding the Python language
>> entirely, we guarantee having to deal with problems 3 and 4 anyway -
>> but by discouraging it, we're buying significant long-term
>> maintainability costs. It especially disturbed me to hear of Python
>> commands being recoded in C - that is definitely not the right
>> direction for reducing expected defect counts, if only because of
>> memory-management issues.
>>
>> We're behind the best-practices curve here.  The major Linux
>> distributions, which have to deal with almost the same set of
>> tradeoffs we do, went to Python for pretty much all glue and
>> administration scripts outside /etc a decade ago, and the decision has
>> served them well.
>>
>> That, among other things, means up-to-date versions of Python are
>> ubiquitous unless we're looking at Windows - in which case Perl and
>> shell actually become much bigger portability problems.  Mac OS X
>> has kept up to date, too; Lion shipped 2.7.1 and that was a major
>> release back at this point.
>>
>> To be fair, there was a time when being a bit twitchy about Python
>> version skew and deployment breadth was justified, but I believe that
>> time is now well past us. My basis for believing this is very simple -
>> I maintain a lot of Python code for systems programmers with stiff
>> portability requirements (things like reposurgeon, coverity-submit,
>> freecode-submit, shipper, and the Python tools in gpsd). I know what
>> kinds of bug reports I get and what kinds I don't, and in the last
>> few years "this breaks on my Python version" has gone from unusual
>> to doesn't-happen.
>>
>> I think my experience with gpsd is particularly instructive.  Like
>> git, that project has a C core with Python wrappers and extension
>> components. Like git, it gets deployed in a lot of odd places by people
>> who cannot afford the time to be tolerant about cross-platform
>> problems and are quite willing to hit the maintainer with a clue-bat
>> when they encounter them.  The good news is - they don't have to.
>>
>> I should also point out that none of Mercurial's problems seem to
>> have anything to do with the fact that it's written in Python...
>>
>> I think we can choose a better policy based on some simple premises.
>>
>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>> 2008) and be pretty much guaranteed it will be anywhere we want to
>> deploy except Windows.  Windows will remain a problem because Python
>> isn't part of the stock install, but that's an equal or worse problem
>> for shell and Perl - and at least the Python project ships a binary
>> installer for Windows.
>>
>> 2) Python extension commands should test the Python version on startup
>> and die loudly but gracefully in the rare case that they don't find
>> what they need.
>>
>> 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.
>>
>> 4) We should be encouraging C code to move to Python, too.  There's
>> little gain in portability on this path because modern C has cleaned
>> up its act a lot, but the drop in expected bug loads would be well
>> worth the porting effort.  Segfaults are not your friend, and the x2 to
>> x5 drop in line count would do very good things for long-term
>> maintainability.

Git for Windows simply ships everything we need to run git - so if a
desirable module requires a version of python, we will add that
version plus any required modules into the installer. We already have
a patch to provide python in the msysgit tree - it would just require
polishing up a little. I'm certain this is no problem for the other
windows port (cygwin) either.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]