PyCharm debugger hangs in version.git_sha()

[hannes-ucsc]

Hi,

I am trying to debug an application I wrote that's using Fabric. It used to work until today and can't remember what changed. I'm not sure my problem is caused solely by Fabric but I think Fabric contributes.

When running my application in PyCharm using its debugger, the application hangs on

from fabric.operations import sudo

I stepped through the import and ultimately it is the Popen in versions.git_sha() that hangs. I don't know why, but the debugger follows the child of the fork() that's done in Popen. I don't know what the debugger does on the parent process.

I'm fairly new to Python, but I find it rather unorthodox ;-) that Fabric runs a shell command during an import. The intention seems to be to get the current git commit for rendering the version string. However, I installed my Python using Homebrew for Mac OS X which means that all installed Python packages are underneath Homebrew's top-level git working copy. This means that the git log command run by git_sha uses Homebrews log, not Fabric's.

Can we add a check for a .git directory before running git log?

[Vye]

hannes-ucsc,

I'm not experiencing this issue with Fabric 1.5.1/1.7.0 and PyCharm 2.7.2 on OS X.

The following produces no problems for me running in PyCharm's debugger:

from fabric.operations import sudo

def host_type():
    sudo('uname -v')

PyCharm debugger I/O:

/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python /Applications/PyCharm.app/helpers/pydev/pydevd.py --multiproc --client 127.0.0.1 --port 54636 --file /usr/local/bin/fab host_type
pydev debugger: process 33647 is connecting

Connected to pydev debugger (build 129.314)
No hosts found. Please specify (single) host string for connection: localhost
[localhost] sudo: uname -v
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
[localhost] Passphrase for private key: secret

[localhost] out: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64

It's worth noting that in the past PyCharm's debugger was not always good at handling user input scenarios (and still is lacking when it comes to getpass). Maybe you can update this issue with your fabric, python, and PyCharm version?

I installed fabric via pip. Maybe try that? That should narrow down whether this issue is with fabric itself or how it was installed.

[hannes-ucsc]

My PyCharm version is 2.7.3. I installed Python via Homebrew and Fabric via the homebrewed Python's pip. In my PyCharm project that Python (not the OS X stock Python) is selected as the interpreter.

hannes-mbpr:cghub-cloud-utils hannes$ pip freeze
Fabric==1.7.0
Jinja2==2.7
MacFSEvents==0.3
MarkupSafe==0.18
MySQL-python==1.2.4
PyYAML==3.10
Pygments==1.6
Sphinx==1.2b1
boto==2.9.7
distribute==0.6.45
docutils==0.10
git-remote-helpers==0.1.0
lxml==3.2.1
mock==1.0.1
numpy==1.7.1
ordereddict==1.1
oset==0.1.3
oursql==0.9.3.1
paramiko==1.11.0
pybtex==0.16
pycrypto==2.6
sphinxcontrib-bibtex==0.2.6
tornado==3.1
vboxapi==1.0
virtualenv==1.10
wsgiref==0.1.2

hannes-mbpr:cghub-cloud-utils hannes$ python --version
Python 2.7.5
hannes-mbpr:cghub-cloud-utils hannes$ which python
/usr/local/bin/python

BTW: If you are trying to reproduce this, you can reduce the repro code to

from fabric.operations import sudo

because that's all it takes for me to hang it.

As a workaround, I commented out the call to git_sha and the hang doesn't occur anymore.

[berimor]

I solved this problem by switching off the option "Attach to subprocess automatically while debugging" in Pycharm preferences -> "Python Debugger".

[bitprophet]

Linking to #147, #749 as they're semi related.

I agree that using the git SHA version junk is suboptimal when it causes issues like this, though it also doesn't come up often, and it sounds like there are workarounds re: Pycharm's triggering behavior, as per @berimor.

That said, clearly it affects multiple people, I've abandoned this sort of "super rich versioning" for newer projects, and it never proved as useful in troubleshooting as I had hoped (most users on real git checkouts are savvy enough to provide the SHA themselves or to submit it on request). So I might just consider it a bug and rip it out.