virtualenv przy tworzeniu wirtualnych środowisk Python'avirtualenv - narzędzie, które pozwala na zarządzanie oddzielnymi instalacjami pakietów i wersjami Pythona dla różnych projektów.
Utworzenie wirtualnego środowiska Pythona umożliwia instalowanie pakietów Pythona w odizolowanej lokalizacji dla określonej aplikacji, zamiast instalować je globalnie (standardowo z dostępem dla całego systemu).
Podczas pracy nad danym projektem można po prostu stworzyć nowe środowisko wirtualne, bez obaw o konflikty, nie zawsze kompatybilnych wersji Pythona i pakietów zainstalowanych globalnie czy w innych środowiskach dotyczących innego projektu.
Wirtualne środowiska zapobiegają sytuacji, w której jest jedna standardowa (globalna) lokalizacja instalacji pakietów np. dla dwóch aplikacji, wymagających dwóch róznych wersji danej biblioteki. Często na współdzielonym hoście nie ma nawet możliwości instalacji pakietów w globalnym-systemowym katalogu - konieczne są wtedy środowiska wirtualne.
Środowiska wirtualne posiadają własne katalogi instalacyjne i nie współdzielą bibliotek z innymi środowiskami wirtualnymi .
Obecnie istnieją dwa narzędzia do tworzenia środowiska wirtualnych - venv i virtualenv.
Moduł venv nie oferuje wszystkich funkcji virtualenv.
Zalecamy zatem korzystanie z virtualenv, który obsługuje Python 2.7+ i Python 3.3+
virtualenv w zadaniu interaktywnym¶ Uruchomianie zadania interaktywnego
Aby uruchomić zadanie interaktywne należy użyć komendy
srunjak niżej(podane przykładowe wartości flag):
srun -n 2 --mem=10gb -c4 --time=00:10:00 --pty bash
jeśli komenda
srunz parametrami/flagami zostanie wywołana w węźle logowania ( ui.wcss.pl ) utworzony zostanie nowy przydział zasobów oraz uruchomiony psedoterminal--ptypowłoka systmowabash
więcej o zadaniach interaktywnych i parametrach/flagach w dokumentacji WCSSu -SLURM urchamianie zadań
virtualenvPoniżej uruchamiamy zadanie interaktywne, sprawdzamy czy konkretna wersja Pythona jest dostępna, nastepnie ładujemy dany moduł
abc@ui: ~ $ srun -n2 --mem=1gb -c2 --time=00:10:00 --pty bash
[wcss] abc@r23c01b11 ~ > module av python
------------------------------------------------------------- /usr/local/easybuild/modules/all ------------------
Python/2.7.15-foss-2018b Python/2.7.18-GCCcore-10.3.0-bare Python/3.8.2-GCCcore-9.3.0 Python/3.9.6-GCCcore-11.2.0-bare
Python/2.7.15-GCCcore-8.2.0 Python/2.7.18-GCCcore-11.2.0-bare Python/3.8.6-GCCcore-10.2.0 Python/3.10.4-GCCcore-11.3.0
Python/2.7.16-GCCcore-8.3.0 Python/2.7.18-GCCcore-11.3.0-bare Python/3.9.5-GCCcore-10.3.0 Python/3.10.4-GCCcore-11.3.0-bare
Python/2.7.18-GCCcore-9.3.0 Python/3.7.2-GCCcore-8.2.0 Python/3.9.5-GCCcore-10.3.0-bare
Python/2.7.18-GCCcore-10.2.0 Python/3.7.4-GCCcore-8.3.0 Python/3.9.6-GCCcore-11.2.0
[wcss] abc@r22c03b01 ~ > module load Python/3.10.4-GCCcore-11.3.0
Loading Python/3.10.4-GCCcore-11.3.0
Loading requirement: GCCcore/11.3.0 zlib/1.2.12-GCCcore-11.3.0 binutils/2.38-GCCcore-11.3.0 bzip2/1.0.8-GCCcore-11.3.0 ncurses/6.3- GCCcore-11.3.0
libreadline/8.1.2-GCCcore-11.3.0 Tcl/8.6.12-GCCcore-11.3.0 SQLite/3.38.3-GCCcore-11.3.0 XZ/5.2.5-GCCcore-11.3.0 GMP/6.2.1-GCCcore- 11.3.0libffi/3.4.2-GCCcore-11.3.0 OpenSSL/1.1
Komenda/menadżer pakietów pip z rozszerzeniem list - pozwala sprawdzić, które moduły są już zainstalowane z wybraną wersją Pythona
[wcss] abc@r22c03b01 ~ > pip list
Package Version
----------------------------- ----------
alabaster 0.7.12
...
virtualenv 20.0.18
wcwidth 0.1.9
wheel 0.34.2
Moduł
Python/3.11.5-GCCcore-13.2.0nie zawiera domyślnie w ramach pakietówvirtualenv
KONIECZNE jest dodatkowe załadowanie modułumodule load virtualenv/20.24.6-GCCcore-13.2.0, pakietvirtualenvi wszystkie funckje będą już dostępny tak samo jakby był załadowany w ramach jednego modułu Pythona.
Po załadowaniu wybranej wersji Python 3+, powinien być dostępny virtualenv.
[wcss] abc@r22c03b04 ~ > virtualenv --version
virtualenv 20.14.1
Nie jest możliwa samodzielna instalacja
virtualenvw zadaniu interaktywnym na przydzielonych węzłach, więc jeślivirtualenvpo załadowaniu wybranej wersji Pythona (dotyczy to zwłaszcza 2.+) nie mozna aktywować, proszę pisać na adres kdm@wcss.pl. Administratrzy KDM na Państwa prośbe zainstalują.
virtualenv[wcss] abc@r23c01b11 ~ > python3 -m venv <venvname>
Flaga -m upewnia się, że używasz venv, który jest powiązany z aktywnym plikiem wykonywalnym Pythona.
lub
[wcss] abc@r23c01b11 ~ > virtualenv <venvname>
Gdy otrzymujemy komunikat
ERROR: Could not install packages due to an OSError: [Errno 122] Disk quota exceededzalecamy skorzystanie z Usługi "Przetwórz na superkomputerze"(PD) która udostępnia dedykowane zasoby pamięci dyskowej na długoterminowe przechowywanie danych.
W celu ułatwienia dostępu do katalogu PD, możliwe jest utworzenie symbolicznego linku do katalogu PD za pomocą komendy ln
$ ln -s /lustre/pd01/hpc-xxx-xxxxxxxxxxx /home/username/symlink_do_lustre
Po utworzeniu symbolicznego linku mozemy utworzyć środowisko wirtualnevirtualenvwe wskazanej przestrzeni:
[wcss] abc@r23c01b11 ~ > virtualenv /home/user/symlink_do_lustre/<venvname>
Po aktywowaniu środowiska<venvname>pakiety będą instalowane w folderze dedykowanym instalowanym pakietom/home/user/symlink_do_lustre/<venvname>/libw przestrzeni dyskowej.
Powinno wytworzyć się wirtualne środowisko (output w terminalu poniżej)
created virtual environment CPython3.10.4.final.0-64 in 10436ms
creator ...
added seed packages: pip==22.0.4, setuptools==62.1.0, wheel==0.37.1 activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
Wybrana przez użytkownika nazwa, w przykładzie venvname to jednocześnie lokalizacja katalogów instalacyjnych naszego wirtualnego środowiska (możemy podać absolutną ścieżkę-przykładowa /home/username/venvname, podanie samej nazwy, wygeneruje katalogi obsługujące środowisko wirtualne w bieżącej lokalizacji.
[wcss] abc@r23c01b11 ~ > source <venvname>/bin/activate
(venvname) wskazuje, że poruszamy się i wywołujemy komendy wewnątrz stworzonego środowiska wirtualnego.
(venvname) [wcss] abc@r23c01b11 ~ > python --version
Python 3.10.4
Użycie source w powłokach Unix zapewnia, że zmienne środowiska wirtualnego są ustawiane w bieżącej powłoce, a nie w podprocesie (który następnie znika, nie mając żadnego użytecznego efektu).
pip(venvname) [wcss] abc@r23c01b11 ~ > pip install <package>==<version>
(venvname) [wcss] abc@r23c01b11 ~ > pip install <package> --upgrade
Używając pip install w aktywowanym Środowisku wirtualnym pakiet zostanie zainstalowany w katalogu domowym środowiska wirtualnego i jest dostępny tylko dla tego środowiska wirtualnego.
np.
(venvname) [wcss] abc@r23c01b11 ~ > pip install numpy pandas
Collecting numpy
Using cached numpy-1.24.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.3 MB)
Installing collected packages: numpy
Successfully installed numpy-1.24.2
...
...
Komeda pip list pozwala wylistować wszystkie dotychczas zainstalowane pakiety w naszym środowisku o przykładowej nazwie venvname
pip ,setuptools, wheel są zawsze domyślnie instalowane w tworzonych środowiskach wirtualnych (niezależnie od wersji Pythona ).
(venvname) [wcss] abc@r21c01b16 ~ > pip list
Package Version
---------- -------
numpy 1.24.2
pandas 1.5.3
pip 22.0.4
setuptools 62.1.0
wheel 0.37.1
$ (venvname) [wcss] abc@r23c01b11 ~ > python </path/to/script>.py
virtualenv$ (venvname) [wcss] abc@r23c01b11 ~ > deactivate
Możemy sprawdzić dzięki pip list zainstalowane wersje bibliotek/pakietów globalnie w systemie na węzłach poza naszym odizolowanym środowiskiem (z niego nie mamy do nich dostepu) i dostrzegamy różnicę
Możemy wielokrotnie korzystać z już stworzonego środowiska w zadaniach interaktywnych srun, po załadowaniu odpowiedniego modułu Pythona (wersji, na podstawie której tworzylismy nasze środowisko wirtualnego z którego chcemy teraz ponownie skorzystać) po prostu uaktywniając je polceniem source, jak było wskazane powyzej.
Przydatne jest rejestrowanie, jakie pakiety i w jakich wersjach są instalowane w naszym środowisku wirtualnym.
pip freeze wyświetli listę każdego zainstalowanego pakietu i jego wersji.
> przekieruje dane wyjściowe polecenia pip freeze do utworzonego plik w bieżacej lokalizacji o nazwie (według konwencji ale może byc dowolna) requirements.txt
(venvname) [wcss] abc@r23c01b11 ~ > pip freeze > requirements.txt
(venvname) [wcss] abc@r23c01b11 ~ > cat requirements.txt
numpy==1.24.2
Listę pakietów z wersjami, plik requirements.txt można następnie wykorzystać do ponownego zainstalowania pakietów w innym/nowym środowisku wirtualnym, wykorzystujemy pip z rozszerzeniem
(venvname_NEW) [wcss] abc@r23c01b11 pip install -r requirements.txt
Jeśli plik requirements.txt nie znajduje się w bieżacej lokalizacji konieczna jest podanie ścieżki z pliku np.
(venvname_NEW) [wcss] abc@r21c01b16 ~ > pip install -r </home/nameuser/requirements.txt>
¶ Zadania wsadowe
Aby wysłać zadanie do kolejki, należy najpierw przygotować odpowiedni skrypt, który zawiera informacje na temat alokacji zasobów oraz wykonanywanego programu.
Do wysłania gotowego skryptu nalezy użyć komendysbatchjak niżej:
abc@ui: sbatch name.sh
więcej o uruchamianiu zadań wsadowych i odpowiedniej alokacji zasobów (w skrypcie poprzez zmienne
#SBATCH) w dokumentacji WCSSu-SLURM alokacja zasobów i urchamianie zadań
Warto mieć na uwadze, że użytkownik który alokuje za dużo zasobów, blokuje te zasoby podczas gdy inni nie mogą z nich korzystać.
Przykładowy skrypt przygotowanym do wykonania zadania.
Taki skrypt może zawierać przykładowe parametry #SBATCH:
#!/bin/bash
#SBATCH --job-name=MyJob
#SBATCH --output=result.out
#SBATCH --error=errlog.err
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --mail-user=<nameuser@pwr.edu.pl>
#SBATCH -N1
#SBATCH -c10
#SBATCH --mem=10G # Total memory per task (units: K,M,G,T)
#SBATCH --time=1:00:00
source /usr/local/sbin/modules.sh
module load Python/<version>
virtualenv <path/to/venvname>
source <path/to/venvname>/bin/activate
pip install <numpy> <pandas> <scipy> # SPACJĄ oddzielamy pakiety,które chcemy zainstalować
pip freeze > </path/to/requirements_name.txt> # opcjonalnie można wygenerować plik requirements.txt w wybranej lokalizacji
python </path/to/script.py>
Pod podaną przez nas ścieżką będzie utworzone środowisko wirtualne o wybranej przez nas nazwie wraz (opcjonalnie) z plikiem requirements_name.txt
w skrypcie wsadowym możemy na jego podstawie odwtorzyć konkretną konfigurację pakietów, po podaniu parametrów #SBATCH fragment:
....
source /usr/local/sbin/modules.sh
module load Python/<version>
virtualenv <path/to/venvname>
source <path/to/venvname>/bin/activate
pip install -r </path/to/requirements_name.txt> # pobiera wskazane w pliku pakiety i biblioteki Pythona
python </path/to/script.py>
Przykładowy skrypt
Ważne, aby wersja ładowanego modułu Pythona zgdzała się z wersją Pythona, na podstawie ktorego zostało stworzone środowisko virtualenv
#!/bin/bash
#SBATCH --job-name=MyJobName
#SBATCH --output=result.out
#SBATCH --error=errlog.err
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --mail-user=<nameuser@pwr.edu.pl>
#SBATCH -N1
#SBATCH -c10
#SBATCH --mem=10G # Total memory per task (units: K,M,G,T)
#SBATCH --time=1:00:00
source /usr/local/sbin/modules.sh
module load Python/<version>
source <path/to/your/virtualenv>/bin/activate
python <your_script.py>
polecenie
source <venvname>/bin/activateaktywuje utworzone środowisko wirtualne
To polecenie musi nastąpić po załadowaniu odpowiedniego modułu Pythona i przed wykonaniem skryptu Pythona.
Tak utworzone środowisko wirtualne w zadaniu wsadowym możemy ponownie wykorzystać także w zadaniu interaktywnym srun odpowiednio ładując (komendamodule load <Python/x.x.x>) moduł Pythona i aktywując dane środowisko (polecenie source <nazwa_VE>/bin/activate)