On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> Nit: s/it is supported/it has been supported/
Thanks, I'll fix in the re-roll.
> I think this would be a good Python policy.
> I would hate to junk up all Python code with things like
> ' '.encode('ascii')
> though, so maybe we should establish a small Python library of
> compatibility utilities (like a small "six"). It could contain b().
> Another handy utility function could be
> def check_python_version(minimum_v2=0x02060000,
> which checks our default Python requirements by default, but is
> overrideable by specific scripts if they know that they can deal with
> older Python versions.
> 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:
|-- Makefile # existing file pulled out of git_remote_helpers
|-- < some new utility library >
| |-- __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 as already taken the "git" module
name, so perhaps we should use "git_core" if we do introduce a new
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html