webentwicklung-frage-antwort-db.com.de

Seltsames Mischen von System + Homebrew-Python mit LLDB

Wenn ich versuche, den Python-Interpreter in lldb auszuführen, sehe ich Folgendes:

$ lldb
(lldb) script
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 52, in <module>
    import weakref
  File "/usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/lib/python2.7/weakref.py", line 14, in <module>
    from _weakref import (
ImportError: cannot import name _remove_dead_weakref
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.

Wenn ich nachschaue, welche Version von Python gestartet wurde, meldet Python, dass es sich um den Homebrew-Python handeln sollte (der an dieser Stelle mit einem Link verknüpft ist):

>>> sys.executable
'/usr/local/opt/python/bin/python2.7'

Bei der Abfrage der Python-Version wird jedoch die Version zurückgegeben, die der Standardinstallation von system Python zugeordnet ist, z.

>>> sys.version_info
sys.version_info(major=2, minor=7, micro=10, releaselevel='final', serial=0)

Die Python-Version im Binärpfad oben ist in der Tat anders (beachten Sie den Unterschied in der Mikroversion):

$ /usr/local/opt/python/bin/python2.7 --version
Python 2.7.14

$ /usr/bin/python --version
Python 2.7.10

Um das Ganze noch verwirrender zu machen, ist der Name _remove_dead_weakrefist im _weakref-Modul für meine Homebrew Python-Installation vorhanden, aber nicht die Standardsysteminstallation:

$ /usr/bin/python -c "import _weakref; print _weakref._remove_dead_weakref"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute '_remove_dead_weakref'

$ /usr/local/opt/python/bin/python2.7 -c "import _weakref; print _weakref._remove_dead_weakref"
<built-in function _remove_dead_weakref>

Irgendeine Idee, was dieses scheinbare Übersprechen zwischen meinen Python-Installationen mit LLDB verursachen könnte? Wie kann ich das verhindern?

16
Kevin Ushey

Eine Problemumgehung für dieses Problem besteht darin, LLDB explizit nur mit der System-Python-Installation auf dem PATH zu starten, z.

PATH=/usr/bin /usr/bin/lldb

Es scheint, als würde LLDB die PATH für die "aktive" Python-Installation abfragen. Wenn Sie eine Homebrew-Installation von Python für die PATH haben, können Sie diese Art von Übersprechen treffen, wenn LLDB versucht, Python zu starten.

14
Kevin Ushey

Sie können einfach brew unlink [email protected] anstatt es zu deinstallieren. Dadurch wird Homebrews Python 2.x aus Ihrem PATH entfernt. Viele Homebrew-Formeln hängen von Homebrews Python 2.x ab, sodass Sie den Brau- Python 2.x installiert und gleichzeitig den Fehler mit lldb behoben.

Wenn Sie Ihr Homebrew-Setup mit Homebrew Bundle verwalten, können Sie diese Zeile zu Ihrem Brewfile hinzufügen:

brew "[email protected]", link: false
4
rootbeersoup

Wenn wir lldb mit DYLD_PRINT_LIBRARIES=1 set ausführen, können wir sehen, dass es das Python.framework aus/System/Library lädt, aber dann einige andere Python-Bibliotheken von Homebrew:

dyld: loaded: /System/Library/Frameworks/Python.framework/Versions/2.7/Python
...
dyld: loaded: /usr/local/Cellar/[email protected]/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so

Wenn wir jedoch DYLD anweisen, Python.framework speziell von Homebrew zu laden, funktioniert es:

DYLD_FRAMEWORK_PATH="$(brew --prefix [email protected])/Frameworks/" lldb

Getestet auf macOS 10.13.6 mit Python 2.7.15.

3
rgov

Ich habe dieses Problem mit der Deinstallation von [email protected] von Homebrew gelöst: https://github.com/flutter/flutter/issues/17803#issuecomment-390980648

UPD:

Wie @Olsonist in Kommentaren feststellt, muss das Ausführen dieses Befehls dieses Problem beheben: brew uninstall --force [email protected] 

0
maksadbek