I’m a heavy lldb user during Icinga 2 development. Most recently I got many of those error messages when starting lldb for debugging Icinga 2.

mbmif /usr/local/icinga2/etc/icinga2/tests (master) # lldb -- /usr/local/icinga2/lib/icinga2/sbin/icinga2 console
(lldb) target create "/usr/local/icinga2/lib/icinga2/sbin/icinga2"
Traceback (most recent call last):
  File "", line 1, in 
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py", line 98, in 
    import six
ImportError: No module named six
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run_one_line' is not defined

Turns out that I have Python2 installed from a dependency in Homebrew. The lldb scripts just use the system path for determining the preferred Python binary.

A sensible workaround is discussed here:

$ /usr/local/bin/pip install six

Works again.

mbmif /usr/local/icinga2/etc/icinga2/tests (master) # lldb -- /usr/local/icinga2/lib/icinga2/sbin/icinga2 console
(lldb) target create "/usr/local/icinga2/lib/icinga2/sbin/icinga2"
Current executable set to '/usr/local/icinga2/lib/icinga2/sbin/icinga2' (x86_64).
(lldb) settings set -- target.run-args  "console"
(lldb) q

Since I wanted to check which package requires python in /usr/local/bin/python I found this command

$ brew list | while read cask; do echo -n "$cask ->"; brew deps $cask | awk '{printf(" %s ", $0)}'; echo ""; done

I can’t get rid of pygtk and macvim, so each new install/update will pull Python again. The reason why they build their own Python is somewhat unsafe C++ functions. Guess I don’t want to dig any deeper here.

%d bloggers like this: