Riferimenti rotti in Virtualenvs

Di recente ho installato un sacco di dotfile sul mio Mac insieme ad alcune altre applicazioni (ho cambiato iTerm invece di Terminal e Sublime come editor di testo predefinito) ma da allora tutti i miei ambienti virtuali hanno smesso di funzionare, sebbene le loro cartelle all'interno di .virtualenvs sono ancora lì e danno il seguente errore ogni volta che provo a eseguire qualcosa in loro:

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

Ho rimosso tutti i file relativi ai dotfile e ho ripristinato il mio .bash_profile a quello che era prima, ma il problema persiste. Esiste un modo per diagnosticare il problema o risolverlo in modo semplice (ad esempio, non è necessario creare di nuovo tutti i VirtualVen)?

Ho trovato la soluzione al problema qui , quindi tutto il merito va all'autore.

L'essenza è che quando si crea un virtualenv, vengono creati molti collegamenti simbolici al Python installato da Homebrew.

Ecco un esempio:

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

Quando aggiorni Python usando Homebrew e poi esegui brew cleanup, i collegamenti simbolici in virtualenv puntano a percorsi che non esistono più (perché Homebrew li ha eliminati).

I collegamenti simbolici devono puntare al Python appena installato:

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 soluzione è rimuovere i collegamenti simbolici in virtualenv e quindi ricrearli:

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

Probabilmente è meglio controllare quali collegamenti verranno eliminati prima di eliminarli:

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

A mio avviso, è ancora meglio eliminare solo i collegamenti simbolici rotti. Puoi farlo usando GNU find:

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

Puoi installare GNU findcon Homebrew se non l'hai già:

brew install findutils

Si noti che per impostazione predefinita, i programmi GNU installati con Homebrew tendono ad avere il prefisso con la lettera g. Questo per evitare di oscurare il findbinario fornito con OS X.

Dopo aver provato alcune cose, questo ha funzionato per me:

vai alla tua directory virtualenv (ma non eseguire workon):

cd ~/.virtualenv/name_of_broken_venv

Ora cancella questi file:

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

Quindi per ricostruire il tuo Venv, esegui:

virtualenv .
workon name_of_broken_venv
pip freeze

Ora dovresti vedere di nuovo un elenco dei pacchetti installati.

Ciò si è verificato durante l'aggiornamento a Mac OS X Mavericks di Snow Leopard. Ho dovuto reinstallare anche la birra in anticipo. Spero che tu abbia eseguito il comando freeze per il tuo progetto con pip.

Per risolvere, è necessario aggiornare i percorsi a cui punta l'ambiente virtuale.

• Installa una versione di Python con brew:

brew install python

• Reinstalla virtualenvwrapper.

pip install --upgrade virtualenvwrapper

• Rimosso il vecchio ambiente virtuale:

rmvirtualenv old_project

• Crea un nuovo ambiente virtuale:

mkvirtualenv new_project

• Lavora su un nuovo ambiente virtuale

workon new_project

• Utilizzare pip per installare i requisiti per il nuovo progetto.

pip install -r requirements.txt

Questo dovrebbe lasciare il progetto com'era prima.

La @Chris Wedgwoodrisposta di una versione di aggiornamento da conservare site-packages(mantenere i pacchetti installati)

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/

Sembra che il modo corretto di risolvere questo problema sia quello di eseguire

 pip install --upgrade virtualenv

dopo aver aggiornato Python con Homebrew.

Questa dovrebbe essere una procedura generale per qualsiasi formula che installa qualcosa come Python, che ha il proprio sistema di gestione dei pacchetti. Quando si installa brew install python, si installa pythone pipe easy_installe virtualenve così via. Quindi, se quegli strumenti possono essere auto-aggiornati, è meglio provare a farlo prima di guardare Homebrew come fonte di problemi.

Se questo è stato causato da un brew upgradePython che ha aggiornato e sei a posto con il downgrade alla versione precedente, prova brew switch python [previous version]ad es brew switch python 3.6.5. Da qui.

istruzioni virtualenvwrapper

Come indicato nella risposta accettata, la causa principale è probabilmente un aggiornamento homebrew che significa che i collegamenti simbolici virtualenv puntano a percorsi python interrotti - vedi i dettagli qui .

Per ogni ambiente virtuale, è necessario riassegnare i collegamenti simbolici in modo che puntino al percorso python corretto (nella birreria). Ecco come farlo con virtualenvwrapper . Qui sto aggiornando un env virtuale chiamato "my-example-env".

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

Tutto fatto.

Chiunque usi pipenv (e dovresti!) Può semplicemente usare questi due comandi - senza che venv sia attivato:

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

Se hai eliminato Python3, prova a risolverlo brew upgrade python3.

Di recente ho affrontato questo. Nessuna delle soluzioni sopra ha funzionato per me. Sembra che in realtà non fosse un problema di Python. Quando stavo correndo

aws s3 ls

stavo ricevendo il seguente errore:

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

Questo significa che l' awseseguibile della libreria verso cui punta o non esiste o è danneggiato, quindi ho disinstallato e reinstallato aws-cliseguendo le istruzioni da questo link e ha funzionato !!

Il problema per me (un utente MacOS) è che brewi collegamenti Python e virtualenvs sono stati aggiornati alla versione precedente che è stata eliminata.

Possiamo verificarlo e risolverlo tramite

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

Ho avuto un problema simile e l'ho risolto semplicemente ricostruendo l'ambiente virtuale con virtualenv .

Utilizzo di Python 2.7.10.

Un singolo comando lo virtualenv path-to-envfa. documentazione

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

Ho avuto un env virtuale rotto a causa di una reinstallazione Homebrew di Python (quindi collegamenti simbolici rotti) e anche di alcune "installazioni sudo pip" che avevo fatto in precedenza. I suggerimenti di Weizhong sono stati molto utili per risolvere i problemi senza dover reinstallare i pacchetti. Ho anche dovuto fare quanto segue per il problema delle autorizzazioni miste.

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

Virtualenvs sono rotti. A volte il modo semplice è quello di eliminare le cartelle venv e ricreare virutalenvs.

Se si utilizza pipenv, solo risolvendo pipenv --rmil problema.

Stavo affrontando lo stesso problema dopo aver aggiornato brew sul mio OSX Catalina.

Dopo aver provato un sacco di cose, trovo che la seguente sia la soluzione migliore e facile.

Inizialmente, elimina l'env virtuale. (Opzionale)

find myvirtualenv -type l -delete

quindi ricreare un nuovo virtualenv

virtualenv myvirtualenv

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

La risposta accettata non funziona per me: il file $WORKON_HOME/*/bin/python2.7non è più un collegamento simbolico, è un eseguibile a tutti gli effetti:

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

La soluzione è purtroppo quella di rimuovere completamente e ricreare da zero tutto gli ambienti virtuali.

Per il riferimento:

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

Il semplice aggiornamento di python3 ha funzionato per me:

brew upgrade python3

Ho provato i primi metodi, ma non hanno funzionato, per me, che stavano cercando di far funzionare tox. Ciò che alla fine ha funzionato è stato:

sudo pip install tox

anche se tox era già installato. L'output è terminato con:

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

Ciò che l'ha risolto per me è stato semplicemente disinstallare python3 e pipenv, quindi reinstallarli.

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

Tutte le risposte sono ottime qui, ho provato un paio di soluzioni sopra menzionate da Ryan, Chris e non sono riuscito a risolvere il problema, quindi ho dovuto seguire un modo rapido e sporco.

1. rm -rf <project dir>(o mv <project dir> <backup projct dir>se si desidera conservare un backup)
2. git clone <project git url>
3. Vai avanti!

Niente di nuovo qui, ma semplifica la vita!

Sono sicuro di essere in ritardo alla festa, ma voglio dire che la risoluzione di questo problema è molto più semplice di quanto discusso qui.

Puoi facilmente rigenerare l'ambiente virtuale senza dover eliminare / modificare nulla. Supponendo che venga chiamato il tuo ambiente danneggiato, env_to_fixpuoi semplicemente:

mkvirtualenv env_to_fix

Ciò rigenererà i collegamenti e risolverà l'ambiente senza la necessità di scaricare da qualche parte lo stato corrente e ripristinarlo.

Mi sono imbattuto nello stesso problema quando indicavo il tempo di esecuzione di Python da 2 a 3 sul mio Mac, indicando l'alias python sul percorso di Python 3. Ricreare quindi un nuovo virtualenv e reinstallare i pacchetti necessari per il mio progetto. Per il mio caso d'uso ho avuto un programma Python che scriveva sul foglio di Google. Elimina alcuni pacchetti che sono diversi dall'implementazione di python 2 e quindi, le cose hanno ripreso a funzionare.