[noisy]

Pytanko do użytkowników #python.a. Gdzie trzymacie katalogi tworzone przez virtualenv w stosunku do projektu?

Teoretyczynie to może być w trzech zupełnie różnych lokalizacjach.

1. trzymanie katalogów virtualenva wewnątrz repozytorium wydaje mi się bez sensu. Binarki w repo będą je tylko sztucznie pompować. Ble... to mi sie nie podoba

2. z kolei ja stosowałem wcześniej taką konwencje, że najpierw tworzyłem sobie (przykladowo w katalogu

~/devel/

katalog virtualenva, np.

~/devel/projekt1/

... w którym to obok standardowych katalogów (

bin

,

include

,

lib

,

local

) tworzyłem sobie katalog z kodem, objęty kontrolą wersji, np. pod nazwą

src

. Niby fajnie, jest porządek, natomiast wkurza mnie dodatkowe zagłębienie katalogu z kodem, wydłużające ścieżkę.

Zagłębienie robi się tym głębsze, jeżeli chcemy np. trzymać kod na githubie, wówczas na najwyższym poziomie trzyma się często licencję, pliki readme, requirenmentsy... czy jeszcze jakieś inne rzeczy, a kod w katalogu niżej, czyli często w takim przypadku kod właściwy może znajdować się np. w

~/devel/projekt1/src/projekt1/

- czyli dość głęboko...

3. A może stosujecie zasade, że macie katalogi virtualenva gdzieś "na boku w stosunku do projektu"? Nieco mniejsze zagłębienie, natomiast łatwiej pomylić, który virtualenv do jakiego projektu, w przypadku podobnych nazw. Sposób nr 2 umożliwia stosowanie zawsze tego samego schematu ścieżki względnej:

source ../bin/activate

#programowanie #dobrepraktyki #python #virtualenv

[S.....c]

@noisy: numer 2 :)

[Pies_]

@noisy: ja trzymam niby jak w 1 ale samo env jest dodane do .gitignore - w rezultacie mam jeden katalog odpowiadający za projekt będący jednocześnie repem, a każdy sam sobie zrobi env'a przy pomocy dołączonego skryptu.

[noisy]

@Pies_: no w sumie, przynajmniej nie ma kolejnego poziomu zagnieżdżenia...

[j.....y]

@noisy: trzymanie venva w repo jest bez sensu. w repo trzymasz plik

requirements.txt

, a po aktywacji venva instalujesz wszystkie paczki przez

pip install -r requirements.txt

same virtualenvy trzymam w

~/.virtualenvs/

.

a zamiast

source ../bin/activate

polecam virtualenvwrapper. Odpalasz wtedy virtualenwy przez:

workon 

.

Dodatkowo wrzuciłem sobie do aliasów:

cddev-here() { DIR=

pwd

; cdvirtualenv && cd bin && echo "alias cddev='cd $DIR'" >> postactivate && cat postactivate; };

odpalam tę

[p.....y]

@noisy: opcja #2, dodatkowe zagłębienie nie jest dla mnie problemem

[noisy]

@jestem_anonimowy: Ta opcja chyba najbardziej mi się podoba :)

[morsik]

@noisy: Ja robię tak:

/src/

/src/

/venv

/requirements.txt

/.gitignore

Gdzie to drzewo projektu, a to faktyczny moduł pythonowy (tak samo dla django robię).

A w

.gitignore

:

/venv/*

*.pyc

*~

*.swp

Dzięki temu łatwo mogę trzymać to wszystko w gicie bez binariów w venvie i łatwo zrobić deployment gdziekolwiek tworzac venva i instalując w nim zależności.

Na pewno nie tak jak podałeś w punkcie 2! Zawsze venv per projekt. Jak się