Czy istnieje sposób na uaktualnienie wersji Pythona używanej w virtualenv (np. Jeśli pojawi się wydanie naprawiające błędy)?

Mógłbym pip freeze --local > requirements.txtwtedy usunąć katalog i pip install -r requirements.txt, ale to wymaga dużo ponownej instalacji dużych bibliotek, na przykład numpy, których często używam.

Widzę, że jest to zaletą przy aktualizacji np. Z wersji 2.6 -> 2.7, ale co z wersją 2.7.x -> 2.7.y?

Widziałeś to ? Jeśli nie zrozumiałem tej odpowiedzi, możesz spróbować utworzyć nową virtualenv na szczycie starej. Musisz tylko wiedzieć, który python będzie używał twojego virtualenv (musisz zobaczyć wersję virtualenv).

Jeśli twoja virtualenv jest zainstalowana z tą samą wersją Pythona, co stara, a aktualizacja pakietu virtualenv nie jest opcją, możesz przeczytać to w celu zainstalowania virtualenv z żądaną wersją python.

EDYTOWAĆ

Przetestowałem to podejście (to, które tworzy nowy virtualenv na szczycie starego) i działało dobrze dla mnie. Myślę, że możesz mieć pewne problemy, jeśli zmienisz język z Pythona 2.6 na 2.7 lub 2.7 na 3.x, ale jeśli po prostu uaktualnisz w tej samej wersji (pozostanie na 2.7, jak chcesz), nie powinieneś mieć problemu, ponieważ wszystkie pakiety są przechowywane w tych samych folderach dla obu wersji Pythona (pakiety 2.7.xi 2.7.y znajdują się w twoim_env / lib / python2.7 /).

Jeśli zmienisz wersję virtualenv python, będziesz musiał ponownie zainstalować wszystkie swoje pakiety dla tej wersji (lub po prostu połącz potrzebne pakiety w folderze pakietów nowej wersji, tj .: twoja_env / lib / python_newversion / site-packages)

Jeśli akurat używasz modułu venv dostarczanego z Pythonem 3.3+, obsługuje on tę --upgradeopcję. Według dokumentów :

Zaktualizuj katalog środowiska, aby używać tej wersji Pythona, zakładając, że Python został uaktualniony na miejscu

python3 -m venv --upgrade ENV_DIR

Zaktualizowany ponownie: Poniższa metoda może nie działać w nowszych wersjach virtualenv. Przed przystąpieniem do modyfikacji starej wersji virtualenv należy zapisać zależności w pliku wymagań (pip freeze > requirements.txt) i wykonać kopię zapasową w innym miejscu. Jeśli coś pójdzie nie tak, nadal możesz utworzyć nową virtualenv i zainstalować w niej stare zależności (pip install -r requirements.txt).

Zaktualizowano: Zmieniłem odpowiedź 5 miesięcy po pierwotnej odpowiedzi. Poniższa metoda jest wygodniejsza i bardziej niezawodna.

Efekt uboczny: naprawia równieżSymbol not found: _SSLv2_methodwyjątek, gdy robisz toimport sslw środowisku wirtualnym po aktualizacji Pythona do wersji 2.7.8.

Wskazówka: Obecnie jest to tylko Python 2.7.x .

Jeśli używasz Homebrew Python w systemie OS X, najpierw deactivatevirtualenv, a następnie zaktualizuj Python:

brew update && brew upgrade python

Uruchom następujące polecenia ( <EXISTING_ENV_PATH>jest ścieżką środowiska wirtualnego):

cd <EXISTING_ENV_PATH>
rm .Python
rm bin/pip{,2,2.7}
rm bin/python{,2,2.7}
rm -r include/python2.7
rm lib/python2.7/*
rm -r lib/python2.7/distutils
rm lib/python2.7/site-packages/easy_install.*
rm -r lib/python2.7/site-packages/pip
rm -r lib/python2.7/site-packages/pip-*.dist-info
rm -r lib/python2.7/site-packages/setuptools
rm -r lib/python2.7/site-packages/setuptools-*.dist-info

Na koniec utwórz ponownie środowisko wirtualne:

virtualenv <EXISTING_ENV_PATH>

W ten sposób stare pliki podstawowe Pythona i biblioteki standardowe (plus setuptoolsi pip) są usuwane, a zainstalowane biblioteki niestandardowe site-packagessą zachowywane i działają, gdy tylko znajdą się w czystym języku Python. Biblioteki binarne mogą wymagać ponownej instalacji, aby działały poprawnie.

Działa to dla mnie w 5 środowiskach wirtualnych z zainstalowanym Django.

BTW, jeśli ./manage.py compilemessagespóźniej nie działa, spróbuj tego:

brew install gettext && brew link gettext --force

Nie byłem w stanie utworzyć nowego virtualenv na starym. Istnieją jednak narzędzia w pip, które znacznie przyspieszają ponowną instalację wymagań w zupełnie nowej wersji. Pip może wbudować każdy element w pliku wymagania.txt w pakiet koła i przechowywać go w lokalnej pamięci podręcznej. Kiedy utworzysz nowy venv i uruchomisz w nim instalację pip, pip automatycznie użyje wstępnie zbudowanych kół, jeśli je znajdzie. Koła instalują się znacznie szybciej niż uruchamianie setup.py dla każdego modułu.

Mój ~ / .pip / pip.conf wygląda następująco:

[global]
download-cache = /Users/me/.pip/download-cache
find-links =
/Users/me/.pip/wheels/

[wheel]
wheel-dir = /Users/me/.pip/wheels

Instaluję wheel ( pip install wheel), a następnie biegam pip wheel -r requirements.txt. To przechowuje zbudowane koła w katalogu wheel w katalogu pip.conf.

Odtąd za każdym razem, gdy instaluję dowolne z tych wymagań, instaluje je z kół, co jest dość szybkie.

Jak zaktualizować wersję Python dla istniejącego projektu virtualenvwrapper i zachować tę samą nazwę

Dodam odpowiedź dla każdego, kto korzysta z doskonałego wirtualnego narzędzia do tworzenia kopii Douga Hellmanna, ponieważ istniejące odpowiedzi nie zrobiły tego dla mnie.

Niektóre kontekst:

• Pracuję nad niektórymi projektami, które są Python 2, a niektóre z nich to Python 3; chociaż chciałbym użyć python3 -m venv, nie obsługuje środowisk Python 2
• Kiedy rozpoczynam nowy projekt, używam tego, mkprojectktóry tworzy środowisko wirtualne, tworzy pusty katalog projektu i do niego dołącza dyski CD
• Chcę nadal używać workonpolecenia virtualenvwrapper do aktywacji dowolnego projektu niezależnie od wersji Pythona

Kierunki:

Powiedzmy, że twój projekt ma nazwę fooi obecnie działa w Pythonie 2 ( mkproject -p python2 foo), chociaż polecenia są takie same, czy uaktualnienie z wersji 2.x do wersji 3.x, 3.6.0 do 3.6.1 itd. Zakładam również, że „ są obecnie w aktywowanym środowisku wirtualnym.

1. Dezaktywuj i usuń stare środowisko wirtualne:

$ deactivate
$ rmvirtualenv foo

Zauważ, że jeśli dodałeś jakieś niestandardowe polecenia do zaczepów (np. bin/postactivate), Musisz je zapisać przed usunięciem środowiska.

2. Ukryj prawdziwy projekt w katalogu tymczasowym:

$ cd ..
$ mv foo foo-tmp

3. Utwórz nowe środowisko wirtualne (i katalog projektu) i aktywuj:

$ mkproject -p python3 foo

4. Zamień pusty wygenerowany katalog projektu na prawdziwy projekt, zmień z powrotem na katalog projektu:

$ cd ..
$ mv -f foo-tmp foo
$ cdproject

5. Zainstaluj ponownie zależności, potwierdź nową wersję Pythona itp .:

$ pip install -r requirements.txt
$ python --version

Jeśli jest to częsty przypadek użycia, rozważę otwarcie PR, aby dodać coś takiego $ upgradevirtualenv/ / $ upgradeprojectdo virtualenvwrapper.

To podejście zawsze działa dla mnie:

# First of all, delete all broken links. Replace  my_project_name` to your virtual env name
find ~/.virtualenvs/my_project_name/ -type l -delete
# Then create new links to the current Python version
virtualenv ~/.virtualenvs/my_project_name/
# It's it. Just repeat for each virtualenv located in ~/.virtualenvs

Pochodzą z:

• https://github.com/1st/python-on-osx#python-virtualenv
• https://gist.github.com/1st/ced02a1c64ac7b82bb27e432eea6b068

Przeniosłem swój katalog domowy z jednego komputera Mac na inny (Mountain Lion do Yosemite) i nie zdawałem sobie sprawy z zepsutego virtualenv, dopóki nie straciłem starego laptopa. Miałem punkt virtualenv do Pythona 2.7 zainstalowany, brewa ponieważ Yosemite był dostarczany z Pythonem 2.7, chciałem zaktualizować moją virtualenv do Pythona systemowego. Kiedy uruchomiłem virtualenvistniejący katalog, pojawiał się OSError: [Errno 17] File exists: '/Users/hdara/bin/python2.7/lib/python2.7/config'błąd. Podczas prób i błędów obejrzałem ten problem, usuwając kilka linków i naprawiając kilka ręcznie. Oto co w końcu zrobiłem (podobnie jak @Rockalite, ale prościej):

cd <virtualenv-root>
rm lib/python2.7/config
rm lib/python2.7/lib-dynload
rm include/python2.7
rm .Python
cd lib/python2.7
gfind . -type l -xtype l | while read f; do ln -s -f /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/${f#./} $f; done

Po tym mogłem uruchomić virtualenv na istniejącym katalogu.

W systemie OS X lub macOS przy użyciu Homebrew do instalacji i aktualizacji Python3 musiałem usunąć dowiązania symboliczne, zanim zacznę python -m venv --upgrade ENV_DIRdziałać.

Zapisałem następujące rzeczy w upgrade_python3.sh, więc będę pamiętał, jak za kilka miesięcy muszę to zrobić ponownie:

brew upgrade python3
find ~/.virtualenvs/ -type l -delete
find ~/.virtualenvs/ -type d -mindepth 1 -maxdepth 1 -exec python3 -m venv --upgrade "{}" \;

AKTUALIZACJA: chociaż na początku wydawało się, że działa dobrze, kiedy uruchomiłem py.test, wystąpił błąd. Na koniec właśnie odtworzyłem środowisko z pliku wymagań.

Jeśli używasz pipenv, nie wiem, czy możliwe jest uaktualnienie środowiska w miejscu, ale przynajmniej w przypadku drobnych uaktualnień wersji wydaje się być wystarczająco inteligentny, aby nie odbudowywać pakietów od zera podczas tworzenia nowego środowiska. Np. Od 3.6.4 do 3.6.5:

$ pipenv --python 3.6.5 install
Virtualenv already exists!
Removing existing virtualenv…
Creating a v$ pipenv --python 3.6.5 install
Virtualenv already exists!
Removing existing virtualenv…
Creating a virtualenv for this project…
Using /usr/local/bin/python3.6m (3.6.5) to create virtualenv…
⠋Running virtualenv with interpreter /usr/local/bin/python3.6m
Using base prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/python3.6
Also creating executable in /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD
Installing dependencies from Pipfile.lock (84dd0e)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 47/47 — 00:00:24
To activate this project's virtualenv, run the following:
 $ pipenv shell
$ pipenv shell
Spawning environment shell (/bin/bash). Use 'exit' to leave.
. /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/activate
bash-3.2$ . /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/activate
(autoscale-aBUhewiD) bash-3.2$ python
Python 3.6.5 (default, Mar 30 2018, 06:41:53) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>>

Chcę tylko wyjaśnić, ponieważ niektóre odpowiedzi odnoszą się do venvinnych, a inne odnoszą się do nich virtualenv.

Użycie flagi -plub --pythonjest obsługiwane virtualenv, ale nie włączone venv. Jeśli masz więcej niż jedną wersję języka Python i chcesz określić, z którą chcesz ją utworzyć venv, zrób to w wierszu poleceń, tak jak to:

malikarumi@Tetuoan2:~/Projects$ python3.6 -m venv {path to pre-existing dir you want venv in}

Możesz oczywiście dokonać aktualizacji za pomocą, venvjak zauważyli inni, ale przy założeniu, że już zaktualizowałeś Python, który został użyty do jego stworzenia venv. Nie możesz dokonać aktualizacji do wersji Pythona, której gdzieś jeszcze nie masz w swoim systemie, więc najpierw upewnij się, że otrzymujesz wersję, którą chcesz, a następnie zrób z niej wszystkie potrzebne opcje.

Krok 1: Zamroź wymóg i zrób kopię zapasową istniejącej środowiska

pip freeze > requirements.txt
deactivate
mv env env_old

Krok 2: Zainstaluj Python 3.7 i aktywuj środowisko wirusowe

sudo apt-get install python3.7-venv
python3.7 -m venv env
source env/bin/activate
python --version

Krok 3: Zainstaluj wymagania

sudo apt-get install python3.7-dev
pip3 install -r requirements.txt

Dla każdego z problemem

Błąd: polecenie „[” / Users / me / Sites / site / venv3 / bin / python3 ”,„ -Im ”,„ surepip ”,„ --upgrade ”,„ --default-pip ”]” zwróciło wartość niezerową status wyjścia 1.

Musisz zainstalować python3.6-venv

 sudo apt-get install python3.6-venv