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,
> minimum_v3=0x03010000)
>
> 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:
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
John
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
