john@xxxxxxxxxxxxx wrote on Fri, 01 Feb 2013 11:16 +0000: > On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote: > > 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). > > > 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. This library idea would be a great help; there are 100-odd calls to git in git-p4, and we've had to deal with getting the arguments and parsing correct. I'd happily switch to using git_core. Probably some elements of GitPython can be used too. I'm not so interested in the raw database manipulation, but the command wrappers look reasonable. -- Pete -- 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