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

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