OSError running Fabric from source on non-git systems

[bitprophet]

Example:

from fabric.api import local
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/api.py",
line 9, in <module>
    from fabric.context_managers import cd, hide, settings, show,
path, prefix, lcd
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/context_managers.py",
line 38, in <module>
    from fabric.state import output, win32
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/state.py",
line 10, in <module>
    from fabric.version import get_version
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/version.py",
line 101, in <module>
    __version__ = get_version('short')
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/version.py",
line 52, in get_version
    sha = git_sha()
  File "/data/data/com.xxx.yyy/files/extras/python/fabric/version.py",
line 22, in git_sha
    stderr=PIPE
  File "/data/data/com.xxx.yyy/files/extras/python/subprocess.py",
line 679, in __init__
    errread, errwrite)
  File "/data/data/com.xxx.yyy/files/extras/python/subprocess.py",
line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

This example comes from an Android system lacking pip or git binaries. I believe the error is legit, as we simply call subprocess.Popen("git xxx"), which should AFAIK blow up on any system lacking Git.

Why this didn't come up before now is probably due to the following:

• This function is only called at install time or during fab --version (and --version is likely rarely invoked)
• Most devs have Git installed somewhere, in which case this will not blow up even if they're not running in a Git checkout (instead, the Popen call will just register a nonzero exit). This is why the call does git_sha() or xxx.

EDIT: Except that should still result in a shell level error (eg bash: git: file not found) and not OSError -- so this might meant Popen itself cannot open the shell it's trying to use (should be /bin/sh by default). Which makes a lot more sense on Android vs other systems.

Fix should be a simple try/except either way.

[bitprophet]

local() itself is obviously going to have the same problem...duh!

[bitprophet]

And there's no graceful workaround for that angle, local simply cannot work in that situation until we tackle #178. Pinning to that guy.