Références cassées dans Virtualenvs


239

J'ai récemment installé un tas de fichiers dot sur mon Mac avec quelques autres applications (j'ai changé pour iTerm au lieu de Terminal et Sublime comme mon éditeur de texte par défaut) mais depuis, tous mes environnements virtuels ont cessé de fonctionner, bien que leurs dossiers à l'intérieur .virtualenvs sont toujours là et ils donnent l'erreur suivante chaque fois que j'essaie d'exécuter quoi que ce soit en eux:

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

J'ai supprimé tous les fichiers liés aux fichiers dot et j'ai restauré mon .bash_profile à ce qu'il était auparavant, mais le problème persiste. Existe-t-il un moyen de diagnostiquer le problème ou de le résoudre de manière simple (par exemple, ne nécessitant pas de recréer tous les virtualenvs)?



Merci pour le commentaire, @unubtu. C'est certainement utile. Mais je ne suis pas non plus en mesure de créer de nouveaux virtualenvs. Mon rmvirtualenvfonctionne toujours mais lorsque j'essaye de lancer mkvirtualenv, j'obtiens l'erreur suivante: -bash: /usr/local/bin/virtualenv: /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/Resour: bad interpreter: No such file or directory Donc, cela semble un problème avec mes chemins python mais je ne peux pas voir où est le problème, car je peux exécuter python et ça semble bien.
2014

1
[mise à jour] J'ai peut-être trouvé le problème, mais je ne suis pas sûr et je ne sais pas vraiment comment le résoudre. Il semble que toutes les virtualenvcommandes fonctionnent maintenant en théorie, mais comme il y a un problème avec python, elles ne font rien. Le vrai problème est donc avec le python de brew. Et je soupçonne que la raison est à cause d'un changement de nom dans les répertoires python. Pour une raison quelconque, toutes ces commandes recherchent python dans le dossier, /usr/local/Cellar/python/2.7.6mais le nom du dossier est en fait /usr/local/Cellar/python/2.7.6_1.
2014

Étant donné que je suis novice, je ne sais pas à quel point il est risqué de changer manuellement le nom de 2.7.6_1 à 2.7.6 et de voir ce qui se passe.
2014

Vous devriez être en mesure de renommer 2.7.6_1à 2.7.6. Si le pire venait au pire, vous pourriez le renommer.
unutbu

Réponses:


370

J'ai trouvé la solution au problème ici , donc tout le mérite revient à l'auteur.

L'essentiel est que lorsque vous créez un virtualenv, de nombreux liens symboliques sont créés vers le Python installé par Homebrew.

Voici un exemple:

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

Lorsque vous mettez à niveau Python à l'aide de Homebrew, puis exécutez brew cleanup, les liens symboliques dans virtualenv pointent vers des chemins qui n'existent plus (car Homebrew les a supprimés).

Les liens symboliques doivent pointer vers le Python nouvellement installé:

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

La solution consiste à supprimer les liens symboliques dans virtualenv puis à les recréer:

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

Il est probablement préférable de vérifier quels liens seront supprimés avant de les supprimer:

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

À mon avis, il est encore mieux de ne supprimer que les liens symboliques brisés. Vous pouvez le faire en utilisant GNU find:

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

Vous pouvez installer GNU findavec Homebrew si vous ne l'avez pas déjà:

brew install findutils

Notez que par défaut, les programmes GNU installés avec Homebrew ont tendance à être préfixés par la lettre g. Ceci pour éviter de masquer le findbinaire fourni avec OS X.


4
+1 gfindétait parfait, car j'avais beaucoup de liens symboliques ininterrompus (par exemple, nodeenv) que je ne voulais pas supprimer
2Toad

3
Une autre façon de supprimer les liens symboliques brisés est d'utiliser la recherche standard:find -L ~/.virtualenvs/my-virtual-env/ -type l | xargs rm
vdboor

J'ai supprimé l'intégralité de mon répertoire virtualenv. maintenant je ne peux pas supprimer les liens symboliques. Aucune des solutions mentionnées sur cette page ne fonctionne pour moi sur mac. j'obtiens toujours la même erreur "image introuvable. Interruption du piège: 6"
Aseem

Ces étapes n'ont pas tout à fait fonctionné pour moi:pip3 freeze dyld: lazy symbol binding failed: Symbol not found: __Py_UnixMain
deed02392

1
Juste pour ajouter, si l'env était avec Python 2, lancez-le avec l'argument virtualenv ~/.virtualenvs/foo -p python2
:,

41

Après avoir essayé quelques choses, cela a fonctionné pour moi:

allez dans votre répertoire virtualenv (mais ne lancez pas workon):

cd ~/.virtualenv/name_of_broken_venv

Maintenant, supprimez ces fichiers:

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

Ensuite, pour reconstruire votre venv, exécutez:

virtualenv .
workon name_of_broken_venv
pip freeze

Vous devriez maintenant voir à nouveau une liste de vos packages installés.


FWIW, je viens d'essayer cette approche après la mise à niveau vers El Capitan et la réinstallation de homebrew, et ma liste de paquets n'a pas été conservée.
Ryan

1
avec pipenv vous pouvez supprimer en faire pipenv --rmet de recréer, pipenv shell,pipenv install
Harry Moreno

14

Cela s'est produit lorsque j'ai mis à jour Mac OS X Mavericks à partir de Snow Leopard. J'ai dû réinstaller le breuvage au préalable aussi. J'espère que vous avez exécuté la commande de gel de votre projet avec pip.

Pour résoudre ce problème, vous devez mettre à jour les chemins d'accès vers lesquels l'environnement virtuel pointe.

  • Installez une version de python avec brew:

brew install python

  • Réinstallez virtualenvwrapper.

pip install --upgrade virtualenvwrapper

  • Suppression de l'ancien environnement virtuel:

rmvirtualenv old_project

  • Créez un nouvel environnement virtuel:

mkvirtualenv new_project

  • Travailler sur un nouvel environnement virtuel

workon new_project

  • Utilisez pip pour installer les exigences du nouveau projet.

pip install -r requirements.txt

Cela devrait laisser le projet tel qu'il était auparavant.


C'était il y a un certain temps et je crois que j'ai finalement fait quelque chose dans ce sens, mais comme je n'avais pas exécuté 'pip freeze> requirements.txt' à l'époque, ce n'était pas la solution la plus efficace. Leçon apprise.
2014

13

La @Chris Wedgwoodréponse d'une version de mise à jour à conserver site-packages(garder les packages installés)

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/

1
C'est au-delà de la perfection. Aide à migrer la version python tout en conservant tous les packages. Si vous suivez cela, n'exécutez pas les instructions de @Chris Wedgewood.
Harish Prasanna

10

Il semble que la bonne façon de résoudre ce problème consiste à exécuter

 pip install --upgrade virtualenv

après avoir mis à niveau python avec Homebrew.

Cela devrait être une procédure générale pour toute formule qui installe quelque chose comme python, qui a son propre système de gestion de packages. Lorsque vous installez brew install python, vous installez pythonet pipet easy_installet virtualenvet ainsi de suite. Donc, si ces outils peuvent être mis à jour automatiquement, il est préférable d'essayer de le faire avant de rechercher Homebrew comme source de problèmes.


Cela a fonctionné pour un problème avec setuptools, en particulier: Avertissement: impossible de trouver l'emplacement svn pour setuptools == 0.6c12dev-r88846
Robert Brisita

1
J'ai appliqué cette solution, puis virtualenv . j'ai exécuté: dans mon environnement virtuel cassé. La version mise à jour a virtualenvensuite recréé les dépendances nécessaires et j'étais prêt à partir. Ce processus était plus autogéré et robuste que la réponse acceptée pour moi.
christang

En 2020, c'est toujours la réponse.
scubabuddha

7

Si cela a été causé par un brew upgradequi a mis à niveau son Python, et que vous êtes d'accord avec la rétrogradation vers la version précédente, essayez brew switch python [previous version], par exemple brew switch python 3.6.5. D'ici.


4

instructions virtualenvwrapper

Comme indiqué dans la réponse acceptée, la cause principale est probablement une mise à jour homebrew qui signifie que vos liens symboliques virtualenv pointent vers des chemins de python cassés - voir les détails ici .

Pour chaque env virtuel, vous devez réaffecter les liens symboliques pour pointer vers le chemin python correct (dans la cave de brassage). Voici comment le faire avec virtualenvwrapper . Ici, je mets à jour un env virtuel appelé "mon-exemple-env".

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

Terminé.


4

Quiconque utilise pipenv (et vous devriez!) Peut simplement utiliser ces deux commandes - sans activer le venv:

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

1
vous pouvez également utiliser pipenv --rmdans le dossier de votre env puispipenv install --dev
Handfeger

2

Si vous avez cassé python3, essayez de le corriger brew upgrade python3pour moi.


2

J'ai récemment fait face à cela. Aucune des solutions ci-dessus n'a fonctionné pour moi. Il semble que ce n'était pas vraiment le problème de Python. Lorsque j'exécutais,

aws s3 ls

j'obtenais l'erreur suivante:

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

cela signifie que l' awsexécutable de la bibliothèque pointe vers soit n'existe pas ou est corrompu, j'ai donc désinstallé et réinstallé en aws-clisuivant les instructions de ce lien et cela a fonctionné !!


2

Le problème pour moi (un utilisateur de MacOS) est que brewles liens Python et virtualenvs ont été mis à jour avec l'ancienne version qui a été supprimée.

Nous pouvons le vérifier et le réparer par

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

Cela a également fonctionné pour réparer les liens rompus après l'installation de Python 3.7 sur un système qui avait Python3.6
lukik

2

J'ai eu un problème similaire et je l'ai résolu en reconstruisant simplement l'environnement virtuel avec virtualenv .


Bienvenue chez SO. Bien que nous vous remercions pour votre réponse, il serait préférable qu'elle apporte une valeur ajoutée en plus des autres réponses. Dans ce cas, votre réponse n'apporte aucune valeur supplémentaire, car un autre utilisateur a déjà publié cette solution. Si une réponse précédente vous a été utile, vous devriez la voter une fois que vous avez suffisamment de réputation
David Buck

1

Utilisation de Python 2.7.10.

Une seule commande le virtualenv path-to-envfait. Documentation

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

1

J'ai eu un env virtuel cassé en raison d'une réinstallation Homebrew de python (donc des liens symboliques cassés) et aussi de quelques "sudo pip install" que j'avais fait plus tôt. Les conseils de Weizhong ont été très utiles pour résoudre les problèmes sans avoir à réinstaller les packages. J'ai également dû faire ce qui suit pour le problème des autorisations mixtes.

sudo chown -R my_username lib / python2.7 / site-packages


Si vous complétez les réponses d'un autre utilisateur, vous devez lui laisser un commentaire afin qu'il puisse le modifier! Belle contribution.
Francisco Peters

Il n'a pas assez de points de réputation pour commenter une réponse.
Tyler Smith

1

Virtualenvs est cassé. Parfois, le moyen le plus simple consiste à supprimer les dossiers venv et à recréer virutalenvs.


1

Si vous utilisez pipenv, le simple fait de pipenv --rmrésoudre le problème.



0

La réponse acceptée ne fonctionne pas pour moi: le fichier $WORKON_HOME/*/bin/python2.7n'est plus un lien symbolique, c'est un exécutable à part entière:

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

La solution est, hélas, de supprimer complètement et de recréer à partir de zéro tous les environnements virtuels.

Pour la référence:

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

Je suppose que c'est parce que cette solution n'est pas obsolète - je viens de l'essayer et elle a résolu mon problème. De plus, je pense que si vous n'avez pas de liens symboliques, vous ne verrez pas l'erreur décrite ici, donc ce commentaire ne devient pas une solution mais une distraction - Ce n'est pas parce que vous avez une version plus récente que tout le monde en a. C'est ma raison pour laquelle le downvote :)
RafazZ

@RafazZ: J'espère que c'est mieux maintenant. Cependant, je me demande pourquoi il s'agit toujours d'un lien symbolique pour vous. Et oui, je reçois cette erreur parce que le python virtualenv est lié aux bibliothèques python stock.
sds

Je pense que le comportement par défaut est toujours de créer des liens symboliques et vous avez besoin d'un --always-copyargument pour le remplacer.
Du

@RafazZ: Je n'ai jamais utilisé --always-copyet j'ai des fichiers réguliers :-(
sds


0

J'ai essayé les quelques meilleures méthodes, mais elles ne fonctionnaient pas, pour moi, qui essayaient de faire fonctionner la toxicité. Ce qui a finalement fonctionné était:

sudo pip install tox

même si tox était déjà installé. La sortie s'est terminée avec:

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

0

Ce qui a résolu le problème pour moi était simplement de désinstaller python3 et pipenv puis de les réinstaller.

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

0

Toutes les réponses sont excellentes ici, j'ai essayé quelques solutions mentionnées ci-dessus par Ryan et Chris et je n'ai pas pu résoudre le problème, j'ai donc dû suivre un chemin rapide et sale.

  1. rm -rf <project dir>(ou mv <project dir> <backup projct dir>si vous souhaitez conserver une sauvegarde)
  2. git clone <project git url>
  3. Passez!

Rien de nouveau ici, mais ça rend la vie plus facile!


0

Je suis sûr que je suis en retard à la fête, mais je tiens à dire que la résolution de ce problème est beaucoup plus simple que celle discutée ici.

Vous pouvez facilement régénérer l'environnement virtuel sans avoir à supprimer / modifier quoi que ce soit. En supposant que votre environnement défectueux est appelé, env_to_fixvous pouvez simplement effectuer les opérations suivantes:

mkvirtualenv env_to_fix

Cela va régénérer les liens et réparer l'environnement sans avoir besoin de vider l'état actuel quelque part et de le restaurer.


0

Je suis tombé sur le même problème lorsque je pointais mon temps d'exécution Python de 2 à 3 sur mon Mac, pointant le chemin d'alias python vers python 3. Je recrée ensuite un nouveau virtualenv et réinstalle les packages dont j'ai besoin pour mon projet. Pour mon cas d'utilisation, j'ai eu un programme python écrit sur une feuille Google. Nettoyez quelques paquets qui sont différents de l'implémentation de python 2 et wa la, les choses ont recommencé à fonctionner.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.