5

I'm working on adding some Python scripting in my lldb sessions, but I've found that it only works when /usr/bin/python is the first Python on the PATH. If I have another Python that is found first on the PATH then as soon as lldb initializes its internal Python system it will get an exception like the following and terminate.

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 548, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 266, in addusersitepackages
    user_site = getusersitepackages()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 241, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 231, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py", line 516, in get_config_var
    return get_config_vars().get(name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py", line 449, in get_config_vars
    import re
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", line 105, in <module>
    import sre_compile
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sre_compile.py", line 14, in <module>
    import sre_parse
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sre_parse.py", line 17, in <module>
    from sre_constants import *
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sre_constants.py", line 18, in <module>
    from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT

Is there some lldb setting or command that will let me leave my PATH alone but still have lldb use /usr/bin/python?

I can also work around the issue by setting PYTHONHOME=/usr, but since I am debugging custom Python builds and Python extensions I would really like to not need to alter the environment. It seems that there should be some way like settings set internal-python /usr/bin/python that I could put in my ~/.lldbinit to tell lldb what to use.

RobinDunn
  • 6,116
  • 1
  • 15
  • 14
  • you would probably need to set your path to include the site-packages and various includes for the python version you want to use ... but yeah Im sure it can be done (I use pycharm and some projects use kivy and its version of python, while others use my regular python install, but im running win7, so it may or may not apply to you) (ps wxPython is great and I use it all the time!) – Joran Beasley Oct 25 '13 at 21:40
  • 1
    Yeah, I can also workaround it by setting PYTHONHOME, but since I am debugging custom Python builds and Python extensions I would really rather not alter the environment. I'll update the question a bit... – RobinDunn Oct 25 '13 at 21:55

1 Answers1

1

LLDB does not actually care so much about the Python binary itself What it does however care a lot about is the Python.framework, since that is what the debugger is linked against

Changing the version of Python from the one shipping with OSX is unsupported, because we use the C API (directly and through SWIG), and assume certain classes/functions/types will be available (you can look at the source code to see exactly what is assumed will work). Since we also use SWIG, not everything that is required of Python is under our direct control (SWIG gets a say there as well), so any scenario in which Python is anything but what ships with OSX (and we tested with) might work, or might not

With that said, you might be able to “tamper” Python.framework to point it to some other build of Python. From there on, you’re on your own.

Enrico Granata
  • 3,303
  • 18
  • 25
  • 1
    Actually what I am looking for is some way to tell lldb to force itself to use the system Python framework like it wants to be doing already. If I have some other Python in the PATH then it appears to be trying to use that Python framework instead of the system framework. If I change the PATH or set PYTHONHOME then it does the right thing again, but then the environment that my debugged process sees will also have those changes if I start the debugged app from within lldb. – RobinDunn Oct 28 '13 at 19:34
  • 1
    Or you could use the lldb process launch command to set/unset your environment as you see fit for your inferior, regardless of the environment for lldb. help process launch at the LLDB prompt has the details – Enrico Granata Oct 29 '13 at 01:07
  • Wow, Xcode replaces gdb with lldb, doesn't statically point it at the only framework that will work, then tells all users to get over it and fix their python. – David M. Rogers Jun 17 '15 at 21:33
  • 1
    FWIW, this appears to be fixed in Yosemite. You can now favor fink's /sw/bin/python and successfully run lldb at the same time. – David M. Rogers Jul 26 '15 at 16:35