Розбиті посилання у Virtualenvs

Нещодавно я встановив на моєму комп’ютері купу точкових файлів разом із деякими іншими програмами (я змінив iTerm замість Terminal та Sublime як мого текстового редактора за замовчуванням), але з тих пір усі мої віртуальні середовища перестали працювати, хоча їх папки всередині .virtualenvs все ще є, і вони дають таку помилку, коли я намагаюся запустити що-небудь у них:

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

Я видалив усі файли, пов’язані з dotfiles, і відновив свій .bash_profile до того, що було раніше, але проблема зберігається. Чи є спосіб діагностувати проблему або вирішити її простим способом (наприклад, не потрібно створювати всі віртуальні знов)?

Я знайшов рішення цієї проблеми тут , так що все заслуга автора.

Суть у тому, що при створенні virtualenv створюється багато посилань на встановлений Homebrew Python.

Ось один із прикладів:

$ 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
...

Коли ви оновлюєте Python за допомогою Homebrew, а потім запускаєте brew cleanup, символьні посилання у virtualenv вказують на шляхи, які більше не існують (оскільки Homebrew їх видалив).

Символьні посилання повинні вказувати на нещодавно встановлений 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

Рішення полягає в тому, щоб видалити символьні посилання у virtualenv, а потім відтворити їх:

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

Напевно, найкраще перевірити, які посилання будуть видалені спочатку перед їх видаленням:

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

На мою думку, ще краще видалити лише зламані символьні посилання. Ви можете зробити це за допомогою GNU find:

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

Ви можете встановити GNU за findдопомогою Homebrew, якщо у вас його ще немає:

brew install findutils

Зауважте, що за замовчуванням програми GNU, встановлені з Homebrew, як правило, мають префікс буквою g. Це дозволяє уникнути затінення findбінарних файлів, що постачаються з ОС X.

Спробувавши кілька речей, для мене це спрацювало:

перейдіть у каталог virtualenv (але не запускайте workon):

cd ~/.virtualenv/name_of_broken_venv

Тепер видаліть ці файли:

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

Потім, щоб відновити свій вентиляційний апарат, запустіть:

virtualenv .
workon name_of_broken_venv
pip freeze

Тепер ви знову побачите список встановлених пакетів.

Це сталося під час оновлення до Mac OS X Mavericks від Snow Leopard. Довелося заздалегідь встановити заварку. Сподіваємось, ви запустили команду заморожування для вашого проекту з допомогою піп.

Щоб вирішити проблему, вам необхідно оновити шляхи, на які вказує віртуальне середовище.

• Встановіть версію python з brew:

brew install python

• Повторно встановіть virtualenvwrapper.

pip install --upgrade virtualenvwrapper

• Видалено старе віртуальне середовище:

rmvirtualenv old_project

• Створіть нове віртуальне середовище:

mkvirtualenv new_project

• Робота над новим віртуальним середовищем

workon new_project

• Використовуйте pip, щоб встановити вимоги до нового проекту.

pip install -r requirements.txt

Це повинно залишити проект, як це було раніше.

Відповідь оновленої версії @Chris Wedgwoodна збереження site-packages(зберігання встановлених пакетів)

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/

Здається, запустити правильний спосіб вирішити цю проблему

 pip install --upgrade virtualenv

після того як ви оновили python до програми Homebrew.

Це має бути загальною процедурою для будь-якої формули, яка встановлює щось на зразок python, у якому є власна система управління пакетами. При установці brew install python, установка pythonі pipта easy_installі virtualenvта так далі. Отже, якщо ці інструменти можна оновити самостійно, найкраще спробувати це зробити, перш ніж шукати Homebrew як джерело проблем.

Якщо це було викликано тим, brew upgradeщо оновлено його Python, і ви все в порядку з переходом на попередню версію, спробуйте brew switch python [previous version], наприклад brew switch python 3.6.5. Звідси.

інструкції щодо virtualenvwrapper

Як зазначено у прийнятій відповіді, першопричиною, ймовірно, є оновлення домашньої версії, що означає, що ваші virtualenv символьні посилання вказують на порушені шляхи python - детальну інформацію тут .

Для кожної віртуальної env вам потрібно перепризначити символьні посилання, щоб вказати на правильний шлях python (у підварі для пивоваріння). Ось як це зробити за допомогою virtualenvwrapper . Тут я оновлюю віртуальну env під назвою "my-example-env".

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

Готово.

Кожен, хто використовує pipenv (і вам слід!), Може просто використовувати ці дві команди - не активуючи venv:

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

Якщо ви зламали python3, просто спробуйте brew upgrade python3це виправити.

Нещодавно я стикався з цим. Жодне з перерахованих вище рішень не працювало для мене. Здається, це насправді не проблема Python. Під час запуску

aws s3 ls

я отримував наступну помилку:

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

Це означає, що awsвиконуваний файл бібліотеки вказує на те, що він або не існує, або пошкоджений, тому я видалив та перевстановив, aws-cliвиконуючи інструкції з цього посилання, і він працював !!

Проблема для мене (користувача MacOS) полягає в тому, що brewоновлено посилання Python і virtualenvs на стару версію, яку було видалено.

Ми можемо перевірити і виправити це

>> 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

У мене була подібна проблема, і я вирішив її, просто відновивши віртуальне середовище virtualenv .

Використання Python 2.7.10.

Одна команда virtualenv path-to-envце робить. документація

$ 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.

У мене була зламана віртуальна середовище через перевстановлення Homebrew python (таким чином, зламані символьні посилання), а також кілька "sudo pip install", які я робив раніше. Поради Weizhong були дуже корисними для вирішення проблем, не потребуючи перевстановлення пакетів. Я також повинен був зробити наступне для змішаної проблеми дозволів.

sudo chown -R my_username lib / python2.7 / site-пакети

Віртуальні розбиті. Іноді простим способом є видалення венв-папок і відтворення virutalenvs.

Якщо ви використовуєте pipenv, просто pipenv --rmвирішення проблеми.

Я зіткнувся з тим же питанням після оновлення варіння на моєму OSX Catalina.

Спробувавши купу продуктів, я знаходжу наступне - найкраще і просте рішення.

Спочатку видаліть віртуальне оточення. (Необов’язково)

find myvirtualenv -type l -delete

потім відтворити новий віртуаленв

virtualenv myvirtualenv

Довідка: https://www.jeremycade.com/python/osx/homebrew/2015/03/02/fixing-virtualenv-after-a-python-upgrade/

Прийнята відповідь для мене не працює: файл $WORKON_HOME/*/bin/python2.7більше не є посиланням, це повноцінний виконуваний файл:

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

На жаль, рішення полягає в тому, щоб повністю видалити та створити з нуля всі віртуальні середовища.

Довідково:

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

Просто оновлення python3 працювало для мене:

brew upgrade python3

Я спробував кілька кращих методів, але вони не спрацювали для мене, які намагалися зробити таксичну роботу. Що в підсумку спрацювало:

sudo pip install tox

навіть якщо токсик вже був встановлений. Вихід закінчується:

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

Що для мене виправлено - це просто видалення python3 та pipenv, а потім їх перевстановлення.

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

Усі відповіді тут чудові, я спробував пару рішень, згаданих вище Райаном, Крісом, і не зміг вирішити проблему, тому довелося дотримуватися швидкого і брудного шляху.

1. rm -rf <project dir>(або mv <project dir> <backup projct dir>якщо ви хочете зберегти резервну копію)
2. git clone <project git url>
3. Рухайся!

Тут нічого роману, але це полегшує життя!

Я впевнений, що я спізнююся з партією, але хочу сказати, що вирішення цієї проблеми набагато простіше, ніж тут обговорювалося.

Ви можете легко відновити віртуальне середовище, не потребуючи нічого видаляти / редагувати. Якщо припустити, що ваше порушене середовище викликається, env_to_fixви можете просто виконати таке:

mkvirtualenv env_to_fix

Це відновить посилання та виправить оточення без необхідності скидати поточний стан десь і відновити його.

Я зіткнувся з тією ж проблемою, коли я вказував мій час роботи пітона від 2 до 3 на моєму mac, вказуючи псевдонім python на python 3 шлях. Потім я відтворюю новий virtualenv і знову встановлюю ті пакунки, які мені потрібні для мого проекту. Для мого використання я мав програму python, що пише на лист Google. Очистіть декілька пакетів, які відрізняються від реалізації python 2 та wa la, все почало працювати знову.