Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines

From: John Keeping <john@keeping.me.uk>
Date: Feb 1, 2013, 11:16 UTC
Message-ID: <20130201111634.GA2476@farnsworth.metanate.com>
In-Reply-To: <510B7F4B.7040902@alum.mit.edu>

On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote:

Show 39 quoted lines

> On 01/30/2013 09:31 PM, John Keeping wrote:
> > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> >> [...] maybe we should establish a small Python library of
> >> compatibility utilities (like a small "six"). [...]
> >> But I haven't had time to think of where to put such a library, how to
> >> install it, etc.
> > 
> > If we want to go that route, I think restructuring the
> > "git_remote_helpers" directory and re-using its infrastructure for
> > installing the "Git Python modules" would be the way to go.  The
> > directory structure would become something like this:
> > 
> >     git/
> >     `-- python/
> >         |-- Makefile    # existing file pulled out of git_remote_helpers
> >         |-- < some new utility library >
> >         |-- git_remote_helpers
> >         |   |-- __init__.py
> >         |   |-- git
> >         |   |   |-- __init__.py
> >         |   |   |-- exporter.py
> >         |   |   |-- git.py
> >         |   |   |-- importer.py
> >         |   |   |-- non_local.py
> >         |   |   `-- repo.py
> >         |   `-- util.py
> >         |-- setup.cfg   # existing file pulled out of git_remote_helpers
> >         `-- setup.py    # existing file pulled out of git_remote_helpers
> > 
> > 
> > It looks like the GitPython project[1] as already taken the "git" module
> > name, so perhaps we should use "git_core" if we do introduce a new
> > module.
> > 
> > [1] http://pypi.python.org/pypi/GitPython
> 
> This sounds reasonable.  But not all Python code will go under the
> "python" subdirectory, right?  For example, I am working on a Python
> script that fits thematically under contrib/hooks.

I was thinking of it as analagous with the "perl" directory that currently exists. So the "python" directory will contain library code but scripts can live wherever is most appropriate.

One way of looking at it is: could the user want to have this installed for all available versions of Python? For a script, the answer is "no" because they will call it and it will just run. For libraries, you want them to be available with whatever Python interpreter you happen to be running (assuming that it is a version supported by the library).

Show 5 quoted lines

> OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
> script to depend on a Python module that is part of git itself.  Doing
> so would make the hook script depend on a particular version of git (or
> at least a version with a compatible Python module).  But users might be
> reluctant to upgrade git just to install a hook script.

I don't think such a dependency is a bad idea in the longer term. If a "Git Python library" is developed, then at some point most people who have Git installed will have some version of that library - it becomes a case of perhaps wanting to limit yourself to some subset of the library rather than just not using it.

In fact, git_remote_helpers has been available since Git 1.7.0 and contains a lot of functionality that is more generic than its name suggests.

John