Zepsute odniesienia w Virtualenvs

Niedawno zainstalowałem na swoim komputerze Mac kilka plików dotfile wraz z kilkoma innymi aplikacjami (zmieniłem na iTerm zamiast Terminal i Sublime jako domyślny edytor tekstu), ale odtąd wszystkie moje środowiska wirtualne przestały działać, chociaż ich foldery w .virtualenvs nadal tam są i za każdym razem, gdy próbuję coś w nich uruchomić, zgłaszają następujący błąd:

dyld: Library not loaded: @executable_path/../.Python
  Referenced from: /Users/[user]/.virtualenvs/modclass/bin/python
  Reason: image not found
Trace/BPT trap: 5

Usunąłem wszystkie pliki związane z plikami kropkowymi i przywróciłem mój profil .bash do poprzedniego stanu, ale problem nadal występuje. Czy jest jakiś sposób na zdiagnozowanie problemu lub rozwiązanie go w prosty sposób (np. Bez konieczności ponownego tworzenia wszystkich wirtualnych wirtualnych programów)?

Tutaj znalazłem rozwiązanie problemu , więc cały kredyt należy się autorowi.

Istotą jest to, że podczas tworzenia virtualenv powstaje wiele dowiązań symbolicznych do zainstalowanego Pythona Homebrew.

Oto jeden przykład:

$ ls -la ~/.virtualenvs/my-virtual-env
...
lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.7/Frameworks/Python.framework/Versions/2.7/Python
...

Po uaktualnieniu Pythona za pomocą Homebrew, a następnie uruchomieniu brew cleanup, dowiązania symboliczne w virtualenv wskazują ścieżki, które już nie istnieją (ponieważ Homebrew je usunął).

Dowiązania symboliczne muszą wskazywać na nowo zainstalowany Python:

lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/Python

Rozwiązaniem jest usunięcie dowiązań symbolicznych w virtualenv, a następnie ich odtworzenie:

find ~/.virtualenvs/my-virtual-env/ -type l -delete
virtualenv ~/.virtualenvs/my-virtual-env

Prawdopodobnie najlepiej sprawdzić, które linki zostaną usunięte przed ich usunięciem:

find ~/.virtualenvs/my-virtual-env/ -type l

Moim zdaniem jeszcze lepiej jest usuwać tylko uszkodzone dowiązania symboliczne. Możesz to zrobić za pomocą GNU find:

gfind ~/.virtualenvs/my-virtual-env/ -type l -xtype l -delete

Możesz zainstalować GNU findz Homebrew, jeśli jeszcze go nie masz:

brew install findutils

Zauważ, że domyślnie programy GNU instalowane z Homebrew zwykle mają literę g. Ma to na celu uniknięcie cieniowania pliku findbinarnego dostarczanego z systemem OS X.

Po wypróbowaniu kilku rzeczy zadziałało to dla mnie:

przejdź do katalogu virtualenv (ale nie uruchamiaj workon):

cd ~/.virtualenv/name_of_broken_venv

Teraz usuń te pliki:

rm -rf .Python bin/python* lib/python2.7/* include/python2.7

Następnie, aby odbudować swój venv, uruchom:

virtualenv .
workon name_of_broken_venv
pip freeze

Powinieneś teraz ponownie zobaczyć listę zainstalowanych pakietów.

Stało się tak, gdy zaktualizowałem system Mac OS X Mavericks do systemu Snow Leopard. Musiałem też ponownie zainstalować napar. Mam nadzieję, że uruchomiłeś polecenie zamrażania dla swojego projektu za pomocą pip.

Aby rozwiązać ten problem, musisz zaktualizować ścieżki wskazane przez środowisko wirtualne.

• Zainstaluj wersję Pythona za pomocą brew:

brew install python

• Ponownie zainstaluj virtualenvwrapper.

pip install --upgrade virtualenvwrapper

• Usunięto stare środowisko wirtualne:

rmvirtualenv old_project

• Utwórz nowe środowisko wirtualne:

mkvirtualenv new_project

• Pracuj w nowym środowisku wirtualnym

workon new_project

• Użyj pip, aby zainstalować wymagania dla nowego projektu.

pip install -r requirements.txt

To powinno opuścić projekt tak, jak było wcześniej.

Odpowiedź wersji aktualizacji @Chris Wedgwoodna utrzymanie site-packages(utrzymanie zainstalowanych pakietów)

cd ~/.virtualenv/name_of_broken_venv


mv lib/python2.7/site-packages ./    
rm -rf .Python bin lib include
virtualenv .
rm -rf lib/python2.7/site-packages
mv ./site-packages lib/python2.7/

Wydaje się, że właściwym sposobem rozwiązania tego problemu jest uruchomienie

 pip install --upgrade virtualenv

po aktualizacji Pythona do Homebrew.

Powinna to być ogólna procedura dla każdej formuły instalującej coś takiego jak Python, który ma własny system zarządzania pakietami. Podczas instalacji brew install python, instalacji pythoni pipi easy_installi virtualenvi tak dalej. Tak więc, jeśli te narzędzia można samodzielnie zaktualizować, najlepiej spróbować to zrobić, zanim zaczniesz szukać Homebrew jako źródła problemów.

Jeśli było to spowodowane przez brew upgradeaktualizację Pythona i nie możesz przejść do poprzedniej wersji, spróbuj brew switch python [previous version]np brew switch python 3.6.5. Stąd.

instrukcje virtualenvwrapper

Jak wskazano w zaakceptowanej odpowiedzi, główną przyczyną jest prawdopodobnie aktualizacja homebrew, co oznacza, że ​​twoje dowiązania symboliczne virtualenv wskazują na uszkodzone ścieżki pytona - zobacz szczegóły tutaj .

Dla każdej wirtualnej env należy ponownie przypisać dowiązania symboliczne, aby wskazywały prawidłową ścieżkę pytona (w piwnicy piwnej). Oto jak to zrobić za pomocą virtualenvwrapper . Tutaj aktualizuję wirtualną env o nazwie „my-example-env”.

cd ~/PYTHON_ENVS
find ./my-example-env -type l -delete
mkvirtualenv my-example-env

Wszystko gotowe.

Każdy, kto używa pipenv (i powinieneś!) Może po prostu użyć tych dwóch poleceń - bez aktywacji venv:

rm -rf `pipenv --venv` # remove the broken venv
pipenv install --dev   # reinstall the venv from pipfile 

Jeśli wyeliminowałeś Python3, po prostu spróbuj brew upgrade python3to naprawić.

Ostatnio miałem z tym problem. Żadne z powyższych rozwiązań nie działało dla mnie. Wygląda na to, że tak naprawdę nie był to problem Pythona. Kiedy działałem

aws s3 ls

, otrzymywałem następujący błąd:

dyld: Library not loaded: @executable_path/../.Python

Oznacza to, że awsplik wykonywalny biblioteki wskazuje, że albo nie istnieje, albo jest uszkodzony, dlatego odinstalowałem i ponownie zainstalowałem aws-cliinstrukcje z tego łącza i działało !!

Problem dla mnie (użytkownika MacOS) polega na tym, że brewzaktualizowałem łącza Python i virtualenvs do starej wersji, która została usunięta.

Możemy to sprawdzić i naprawić

>> ls -al ~/.virtualenvs/<your-virtual-env>/.Python
.Python -> /usr/local/Cellar/python/<old-version>/Frameworks/Python.framework/Versions/3.7/Python
>> rm ~/.virtualenvs/<your-virtual-env>/.Python
>> ln -s  /usr/local/Cellar/python/<new-version>/Frameworks/Python.framework/Versions/3.7/Python ~/.virtualenvs/<your-virtual-env>/.Python

Miałem podobny problem i rozwiązałem go, po prostu odbudowując środowisko wirtualne virtualenv .

Korzystanie z Python 2.7.10.

Wystarczy jedno polecenie virtualenv path-to-env. dokumentacja

$ virtualenv path-to-env
Overwriting path-to-env/lib/python2.7/orig-prefix.txt with new content
New python executable in path-to-env/bin/python2.7
Also creating executable in path-to-env/bin/python
Installing setuptools, pip, wheel...done.

Miałem zepsutą wirtualną env ze względu na ponowną instalację Homebrew Pythona (tym samym zepsute dowiązania symboliczne), a także kilka „sudo pip install”, które zrobiłem wcześniej. Wskazówki Weizhonga były bardzo pomocne w rozwiązywaniu problemów bez konieczności ponownej instalacji pakietów. Musiałem też wykonać następujące czynności dla problemu mieszanych uprawnień.

sudo chown -R moja_nazwa_użytkownika lib / python2.7 / site-packages

Virtualenvs są zepsute. Czasami prostym sposobem jest usunięcie folderów venv i odtworzenie virutalenvs.

Jeśli używasz pipenv, samo działanie pipenv --rmrozwiązuje problem.

Ten sam problem napotkałem po uaktualnieniu naparu na mojej OSX Catalina.

Po wypróbowaniu wielu rzeczy uważam, że poniższe jest najlepszym i łatwym rozwiązaniem.

Najpierw usuń wirtualną środowisko. (Opcjonalny)

find myvirtualenv -type l -delete

następnie odtwórz nowy virtualenv

virtualenv myvirtualenv

Odniesienie: https://www.jeremycade.com/python/osx/homebrew/2015/03/02/fixing-virtualenv-after-a-python-upgrade/

Przyjęta odpowiedź nie działa dla mnie: plik $WORKON_HOME/*/bin/python2.7nie jest już dowiązaniem symbolicznym, jest pełnowartościowym plikiem wykonywalnym:

$ file $WORKON_HOME/*/bin/python2.7
/Users/sds/.virtualenvs/.../bin/python2.7: Mach-O 64-bit executable x86_64
...

Rozwiązaniem jest, niestety, całkowite usunięcie i ponowne utworzenie od podstaw wszystkich środowisk wirtualnych.

Dla odniesienia:

deactivate
pip install --user virtualenv virtualenvwrapper
pip install --user --upgrade virtualenv virtualenvwrapper
for ve in $(lsvirtualenv -b); do
  # assume that each VE is associated with a project
  # and the project has the requirements.txt file
  project=$(cat $WORKON_HOME/$ve/.project)
  rmvirtualenv $ve
  mkvirtualenv -a $project -r requirements.txt $ve
done

Po prostu aktualizacja Python3 działała dla mnie:

brew upgrade python3

Wypróbowałem kilka najlepszych metod, ale one nie działały, dla mnie, które próbowały sprawić, by toksyna działała. Ostatecznie zadziałało:

sudo pip install tox

nawet jeśli toksyna została już zainstalowana. Wyjście zakończyło się:

Successfully built filelock
Installing collected packages: py, pluggy, toml, filelock, tox
Successfully installed filelock-3.0.10 pluggy-0.11.0 py-1.8.0 toml-0.10.0 tox-3.9.0

Naprawiłem to po prostu odinstalowując python3 i pipenv, a następnie ponownie je instalując.

brew uninstall pipenv
brew uninstall python3
brew install python3 
brew install pipenv

Wszystkie odpowiedzi są tutaj świetne, wypróbowałem kilka rozwiązań wspomnianych powyżej przez Ryana, Chrisa i nie mogłem rozwiązać problemu, więc musiałem postępować szybko i brudnie.

1. rm -rf <project dir>(lub mv <project dir> <backup projct dir>jeśli chcesz zachować kopię zapasową)
2. git clone <project git url>
3. Pójść dalej!

Nie ma tu nic nowego, ale ułatwia życie!

Jestem pewien, że spóźniłem się na imprezę, ale chcę powiedzieć, że rozwiązanie tego problemu jest znacznie prostsze niż tutaj omówione.

Możesz łatwo zregenerować środowisko wirtualne bez konieczności usuwania / edytowania czegokolwiek. Zakładając, że wywoływane jest twoje uszkodzone środowisko env_to_fix, możesz po prostu wykonać następujące czynności:

mkvirtualenv env_to_fix

To zregeneruje łącza i naprawi środowisko bez konieczności zrzucania gdzieś bieżącego stanu i przywracania go.

Ten sam problem napotkałem, gdy wskazywałem czas działania Pythona od 2 do 3 na komputerze Mac, wskazując alias python na ścieżkę Python 3. Następnie odtwarzam nowy virtualenv i ponownie instaluję pakiety potrzebne do mojego projektu. W moim przypadku miałem program napisający w Pythonie, który pisze w arkuszu google. Wyczyść kilka pakietów, które różnią się od implementacji Pythona 2 i wa la, wszystko zaczęło działać ponownie.