Gdzie należy tworzyć wirtualne envy?

107

Nie mam pojęcia, gdzie powinienem umieścić moje virtualenvy.

W moim pierwszym projekcie django utworzyłem projekt za pomocą polecenia

django-admin.py startproject djangoproject

Następnie przeszedłem do katalogu djangoproject i uruchomiłem polecenie

virtualenv env

który utworzył katalog środowiska wirtualnego na tym samym poziomie co djangoprojectkatalog wewnętrzny .

Czy to niewłaściwe miejsce do tworzenia virtualenv dla tego konkretnego projektu?

Odnoszę wrażenie, że większość ludzi trzyma wszystkie swoje virtualenvy razem w zupełnie innym katalogu, np. ~/virtualenvs, A następnie używa virtualenvwrapper do przełączania się między nimi.

Czy jest na to właściwy sposób?

python virtualenv virtualenvwrapper Promień
źródło

Odpowiedzi:

128

Wiele osób korzysta z narzędzia virtualenvwrapper , które utrzymuje wszystkie virtualenv w tym samym miejscu ( ~/.virtualenvskatalogu) i umożliwia skróty do ich tworzenia i przechowywania. Na przykład możesz zrobić:

mkvirtualenv djangoproject

a później:

workon djangoproject

To prawdopodobnie zły pomysł, aby zachować katalog virtualenv w samym projekcie, ponieważ nie chcesz go dystrybuować (może to być specyficzne dla twojego komputera lub systemu operacyjnego). Zamiast tego zachowaj plik Require.txt za pomocą pip :

pip freeze > requirements.txt

i rozpowszechniaj to. Umożliwi to innym osobom korzystającym z Twojego projektu ponowne zainstalowanie tych samych wymagań w ich virtualenv za pomocą:

pip install -r requirements.txt
David Robinson
źródło
fajnie, nigdy nie zaglądałem do rzeczy o pipach, ale jeśli będę potrzebował któregoś dnia to się przyda
Joran Beasley
pip jest bardzo popularny w społeczności Django i bardzo łatwy w użyciu.
David Robinson
Dzięki David, tak właśnie myślałem. Wiedziałem o wymaganiach i robię to. Po prostu nie byłam pewna, gdzie powinien iść wenv. Twój komentarz dotyczący tego, że jest to specyficzne dla systemu operacyjnego, jest dobrym uzasadnieniem robienia tego, co sugerujesz.
Ray
Czy można przenieść środowisko wirtualne po jego utworzeniu? Nieświadomie umieściłem to w katalogu mojego projektu
James Wierzba
6
Nie jest to świetne uzasadnienie IMO. Czy nie po to jest .gitignore?
Josh Noe
24

Zmiana lokalizacji katalogu virtualenv przerywa to

Jest to jedna z zalet umieszczenia katalogu poza drzewem repozytorium, np. Pod ~/.virtualenvsz virutalenvwrapper.

W przeciwnym razie, jeśli zachowasz go w drzewie projektu, przeniesienie lokalizacji projektu spowoduje uszkodzenie virtualenv.

Zobacz: Zmiana nazwy folderu virtualenv bez niszczenia go

Jest, --relocatableale wiadomo, że nie jest doskonały.

Kolejna drobna zaleta: nie musisz tego robić .gitignore.

Zalety umieszczenia go gitignored w samym drzewie projektu to:

  • utrzymuje powiązane rzeczy blisko siebie.
  • prawdopodobnie nigdy nie użyjesz ponownie danego virtualenva w różnych projektach, więc umieszczenie go w innym miejscu nie daje dużej korzyści
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
źródło
3
To jedyny rozsądny argument, jaki widziałem, dotyczący tworzenia folderów virtualenv poza drzewami projektów! Inne wytyczne wydają się po prostu powtarzać dogmat „centralizacji”, tak jakby były z natury najlepszą praktyką zamiast niefortunnego kompromisu z powodu fundamentalnego zerwania wirtualnych urządzeń (choć całkiem przydatne!).
rob3c
Przepraszam, że coś nie jest dla mnie jasne, więc czy rekomendujesz utworzenie tego w drzewie projektu, a następnie „gitignorowanie”, czy utworzenie w ~ / .virtualenvs? Do czego odnosi się „Gdyby nie to”?
aderchox
1
@aderchox jest kompromis: umieść go w drzewie projektu i przesunie drzewo, które musisz ponownie zainstalować lub umieścić w ~ ale zarządzaj w dodatkowym podkatalogu poza projektem.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
5

Powszechnie akceptowanym miejscem ich umieszczenia jest to samo miejsce, w którym umieszcza je domyślna instalacja virtualenvwrapper: ~/.virtualenvs

Powiązane: virtualenvwrapper to doskonałe narzędzie, które udostępnia skróty do typowych poleceń virtualenv. http://www.doughellmann.com/projects/virtualenvwrapper/

Emmett Butler
źródło
0

Jeśli używasz pyenv install Python, pyenv-virtualenv będzie najlepszą praktyką. Jeśli ustawisz .python-versionplik, może automatycznie aktywować lub dezaktywować wirtualne środowisko env po zmianie folderu roboczego. Pyenv-virtualenvrównież umieść wszystkie wirtualne env w $HOME/.pyenv/versionsfolderze.

Aston
źródło
0

Z własnego doświadczenia radziłbym zorganizować wszystkie środowiska wirtualne w jednym katalogu. Chyba że ktoś ma wyjątkowo ostrą pamięć i może zapamiętać pliki / foldery rozproszone po całym systemie plików. Nie jest wielkim fanem używania innych narzędzi tylko do zarządzania środowiskami wirtualnymi. W VSCode, jeśli skonfiguruję ( python.venvPath) katalog zawierający wszystkie środowiska wirtualne, może automatycznie rozpoznać je wszystkie.

Tejas Sarade
źródło