lion137
2018-11-02 20:41

Pakiety w Pythonie

Dawno nie było nic o Pythonie, to jest. Znowu dość praktycznie: pakiety. Jak tworzymy, jak są izolowane, jak wygląda w nich praca.
Jeśli chcemy napisać coś większego w Pythonie, dobrze jest zacząć od stworzenia środowiska wirtualnego:

➜  test git:(master) ✗ python3.7 -m virtualenv --no-site-packages venv
Using base prefix '/usr/local'
New python executable in /home/lion/code/workspace/python/tests/test/venv/bin/python3.7
Not overwriting existing python script /home/lion/Code/workspace/python/tests/test/venv/bin/python (you must use /home/lion/Code/workspace/python/tests/test/venv/bin/python3.7)
Installing setuptools, pip, wheel...
done.

Aktywujemy je:

➜  test git:(master) ✗ source venv/bin/activate 

I jak teraz sprawdzimy, jakie mamy zainstalowane pakiety, lista jest pusta (pip, jako nakładka na setuptools służy do instalacji, listowania, itp...):

(venv) ➜  venv git:(master) ✗ pip freeze
(venv) ➜  venv git:(master) ✗ 

Lista jest pusta. Kilka uwag, Komenda --no-site-packages słuźy do kompletnego odizolowania środowiska (tak dla pewności, Python domyślnie może tego nie robić). W naszym mini unixowym drzewie katalogów mamy plik wykonawczy Pythona (i kilka innych), jest to dokładnie ta sama wersja, którą użyliśmy do stworzenia środowiska(i będzie do niego przypisana na zawsze). Jesteśmy odseparowani od reszty, cokolwiek nie robimy jesteśmy w naszym venv.
Instalujemy coś:

(venv) ➜  venv git:(master) ✗ pip install pytest
Collecting pytest
 Successfully installed atomicwrites-1.2.1 attrs-18.2.0 more-itertools-4.3.0 pluggy-0.8.0 py-1.7.0 pytest-3.9.3 six-1.11.0
(venv) ➜  venv git:(master) ✗ python
Python 3.7.0 (default, Sep 15 2018, 00:51:17) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytest
>>> pytest.__file__
'/home/lion/code/workspace/python/tests/test/venv/lib/python3.7/site-packages/pytest.py'
>>> 

Jak widać pytest jest w naszym lokalnym (nie globalnie) venv.
Teraz pip freeze:

(venv) ➜  venv git:(master) ✗ pip freeze
atomicwrites==1.2.1
attrs==18.2.0
more-itertools==4.3.0
pluggy==0.8.0
py==1.7.0
pytest==3.9.3
six==1.11.0
(venv) ➜  venv git:(master) ✗ 

Zależności, jeżeli przekierujemy to wyjście do pliku:

(venv) ➜  venv git:(master) ✗ pip freeze > requirements.txt && cat requirements.txt
atomicwrites==1.2.1
attrs==18.2.0
more-itertools==4.3.0
pluggy==0.8.0
py==1.7.0
pytest==3.9.3
six==1.11.0
(venv) ➜  venv git:(master) ✗ 

To mamy gotową listę zależności, teraz możemy ją spakować (plus cokolwiek co mamy w projekcie) i w nowym środowisku wirtualnym możemy my (lub ktokolwiek inny), zainstalować nasz projekt:

(venv) ➜  venv git:(master) ✗ deactivate 
➜  venv git:(master) ✗ python3.7 -m virtualenv --no-site-packages venv2     
Using base prefix '/usr/local'
New python executable in /home/lion/code/workspace/python/tests/test/venv/venv2/bin/python3.7
Also creating executable in /home/lion/code/workspace/python/tests/test/venv/venv2/bin/python
Installing setuptools, pip, wheel...
done.
➜  venv git:(master) ✗ ls
bin  include  lib  requirements.txt  venv2
➜  venv git:(master) ✗ source venv2/bin/activate
(venv2) ➜  venv git:(master) ✗ pip install -r requirements.txt
Successfully installed atomicwrites-1.2.1 attrs-18.2.0 more-itertools-4.3.0 pluggy-0.8.0 py-1.7.0 pytest-3.9.3 six-1.11.0
(venv2) ➜  venv git:(master) ✗ 

Ciekawostka: jeśli zedytujemy requirements.txt, zmienimy wersję jakiegoś pakietu i ponownie odpalimy pip install -r req..., to pip zainstaluje nową i usunie poprzednią, czyli nie mamy opcji zrobienia chaosu z różnymi wersjami pakietu w projekcie:)
To tyle, jak wszystko poszło dobrze:), to powinno śmigać:). Pochwalcie się czymś na githubie:)
#Python #python #theory

Afish

Używam pythona z doskoku i nie znałem pip freeze, ale coś czuję, że przyda się przy następnych zabawach dockerowych!

lion137

Alternatywą jest, coraz bardziej popularna, conda, w zasadzie dla uzupełnienia postu powinienem o niej napisać:)

lion137

@Aryman1983: To w zasadzie wina Pythona;), że ma tak fajnie "Unix style" zorganizowane pakiety.

superdurszlak

Ach, conda, jedyny sposób by zainstalować co poniektóre pakiety na Windowsie nie dostając przy tym pier*lca :v

lion137

Tak, conda jest przyjazna Windowsowi, dlatego też coraz więcej ludzi ją używa; na linuksie, globalny interpreter też mam 3.7.0 z Anacondy.

Julian_

dobrze, że nie znam pythona :O

superdurszlak

A gdzie tam, nie umywa się nawet do C/C++ i tych wszystkich cholernych CMakeFiles z pierdyliardem flag czy kompilowania różnych kawałków kodu zależnie od platformy

superdurszlak

Że już o instalacji jakichś bibliotek pod Windą nie wspomnę, choć pakiety Pythona też często korzystają pod spodem z binarek i są z tym jaja jak np. dwa pakiety używają różnych wersji jednej libki albo wciąga dynamicznie jedną z wielu i zmienia się działanie programu zależnie od tego, co zassie i nawet na *nixie można się strąbić.

lion137

Ogólnie nie ma lekko, takie rzeczy jak pakiety, instalacje, setup środowiska, moga przyprawić o niezły ból głowy. Ale obiektywnie mówiąc, rozwiązanie Pythona wygląda nieżle.

KageYoshi

W windowsie ręczna instalacja jest tragedią :/ setki dziwnych błędów, u każdego spowodowane czym innym. Dla własnego zdrowia psychicznego używam już tylko condy.