Re: Review of git multimail

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jul 4, 2013, 08:27 UTC
Message-ID: <51D531D9.10203@alum.mit.edu>
In-Reply-To: <87ppuzz6xr.fsf@mcs.anl.gov>

Thanks for all of the information.

On 07/03/2013 11:09 PM, Jed Brown wrote:

Show 9 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
> 
>> Yeah, this is good reasoning.  And yes, I'm on Arch: python points to
>> python3, and python2 points to python2.  
> 
> I'm also on Arch and it has been this way since October 2010 [1].
> Ubuntu plans to remove python2 from the desktop CD images in 14.04 [2],
> so having code that does not work with python3 will become more painful
> pretty soon.

It may not be on the CD image, but python2 will undoubtedly continue to be supported in the Ubuntu repositories; i.e., it is just an "apt-get install" away. (For that matter, I don't think Git itself is on the Ubuntu CD image.)

Show 5 quoted lines

> Note that RHEL5 has only python2.4 and will be supported through March,
> 2017.  Since it is not feasible to have code that works in both python3
> and any versions prior to python2.6, any chosen dialect will be broken
> by default on some major distributions that still have full vendor
> support.

I think for a server-oriented program like git-multimail it is more important to support old versions of Python than to support the bleeding-edge versions. For user-oriented programs a different conclusion might be reached.

My vague, long-term plan is roughly:

* Continue to support Python 2.4 or at least 2.5 for the next year or
two.  This excludes any reasonable hope of simultaneously being Python
3.x compatible, so don't worry about 3.x for now (though
backwards-compatible and non-hideous changes that move in the direction
of Python 3.x compatibility are of course welcome).

* At some point, abandon support for the older Python 2.x releases and
start using 3.x-compatibility features that were added in Python 2.6 and
2.7.

* Make string handling Unicode-correct.

* Then evaluate the situation and decide between two courses of action:

  * Evolve the script to work with both Python 2.7 (and maybe 2.6) and
Python 3.3 (and maybe 3.2) simultaneously.

  * Fork development of a Python 3.x version while retaining a 2.x
version in maintenance mode.

Show 11 quoted lines

>> A couple of thoughts while we're on the subject:
>>
>> 1. We should probably convert git-remote-{hg,bzr} to use this style
>> too: 
> 
> Python-2.6.8 from python.org installs only python2.6 and python, but not
> python2, so this will break on a lot of older systems.  Some
> distributions have been nice enough to provide python2 symlinks anyway.
> 
> Michael's rationale that at least the error message is obvious still
> stands.

The approach I've taken in git-multimail isn't necessarily applicable to git-remote-*. The main difference is that git-multimail *has to* be installed by a repository administrator to have an effect (either by being copied or linked to $GIT_DIR/hooks or by adding a script there that refers to git_multimail.py). So the admin, at that time, can decide what python is best to use on his system and adjust the shebang line or create a "python2" symlink or whatever.

The git-remote-* scripts are meant for users, who simply want to execute
them without thinking.  So in that case, the scripts should be installed
to the default $PATH with the correct shebang line already in place for
the local environment.  Thus their shebang lines will tend to be decided
by packagers, not end users, and this difference changes the situation.
 I think they should be managed via build step that rewrites the scripts
to use a build-time-configured Python interpreter.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/