Na początek ciekawostka! Pamiętacie wpis o programowaniu w kawiarni? To dziś w jakimś sensie jest drugie podejście do tematu, bo ten wpis piszę czekając na śniadanie – właśnie w kawiarni. Sama kawiarnia reklamuje się jako śniadaniownia, gdzie mi te określenia wydają się być bardzo podobne… Ale w gruncie rzeczy, jakie to ma znaczenie:)
Pip
Pip czyli Python Package Installer to narzędzie umożliwiające zarządzanie pakietami. Takie narzędzia to dość popularne rozwiązania np. dla Javy jest nim np. Maven dla Node’a istnieje npm a dla Elixira to np. mix.
Jak nazwa wskazuje, takie narzędzia pozwalają nam zarządzać pakietami których używamy w tworzonej przez nas aplikacji. Pakiety od których zależy nasza aplikacja nazywamy „zależnościami” a po angielsku – dependencies. Na 100% spotkałeś się z tą terminologia a jeśli nie – to zawsze warto wiedzieć więcej:)
Używanie pipa
Najprostszy scenariusz używania pip’a to:
1 | pip install nazwa_pakietu |
i jak łatwo się domyśleć – instaluje on nam wskazany pakiet.
Polecenie install pozwala nam, a nie wszyscy o tym wiedzą, by wskazać konkretną wersję biblioteki, np:
1 2 3 | pip install django # instaluje najnowszą wersję pip install django==3.0.2 # instaluje konkretną wersję pip install 'django>=3.0.2' # instaluje wersję nowszą lub równą wskazanej |
Ponad to polecenie pip install posiada kilka przydanych przełączników które warto znać, np:
–no-deps Zainstaluje pakiet bez zależności. Przydatne jeśli wiemy że owe zależności są już zainstalowane.
–force-reinstall Zmusi pipa do przeinstalowania paczki nawet jeśli jest ona w najnowszej wersji.
–index-url Pozwala na podanie innego serwera paczek niż domyślny.
Pip umie instalować z gita!
Tak! Pip zainstaluje nam paczkę prosto z gita! Można to zrobić takim poleceniem:
1 | pip install -e git+https://github.com/psf/requests#egg=requests |
czyli podajemy link do repozytorium i nazwę paczki. Co więcej można zdefiniować jak mamy się do tego repozytorium zautoryzować:
1 2 3 4 5 6 | [-e] git://git.example.com/MyProject#egg=MyProject [-e] git+http://git.example.com/MyProject#egg=MyProject [-e] git+https://git.example.com/MyProject#egg=MyProject [-e] git+ssh://git.example.com/MyProject#egg=MyProject [-e] git+git://git.example.com/MyProject#egg=MyProject [-e] git+file:///home/user/projects/MyProject#egg=MyProject |
i wskazać konkretną gałąź, commit, tag lub refa:
1 2 3 4 | [-e] git://git.example.com/MyProject.git@master#egg=MyProject [-e] git://git.example.com/[email protected]#egg=MyProject [-e] git://git.example.com/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=MyProject [-e] git://git.example.com/MyProject.git@refs/pull/123/head#egg=MyProject |
Sprawa ma się podobnie z svn’em, mercurialem i bazaarem.
Instalacja już ściągniętego repozytorium
Tutaj sprawa jest bajecznie prosta, w folderze gdzie znajduje się plik setup.py uruchamiamy po prostu komendę:
1 | pip install . |
Plik requirements.txt
Standardowym plikiem który przechowuje zależności projektów jest plik requirements.txt. Składnia jest bardzo prosta:
1 2 3 4 5 | SomeProject SomeProject == 1.3 SomeProject >=1.2,<2.0 SomeProject[foo, bar] SomeProject~=1.4.2 |
Jak widzisz sposobów podania wersji jest kilka, nie ma sensu kopiować dokumentacji, więc po prostu zostawiam link do pepa – https://www.python.org/dev/peps/pep-0440/#version-specifiers
Czekaj, stop!
Podoba Ci się to co tworzę? Jeśli tak to zapraszam Cię do zapisania się na newsletter:Jeśli to Cię interesuje to zapraszam również na swoje social media.
Jak i do ewentualnego postawienia mi kawy :)
Plik requirements.txt może zawierać również zmienne środowiskowe, tj np.:
1 2 | SomeProject ==5.4 ; python_version < '2.7' SomeProject; sys_platform == 'win32' |
co pozwalaj uzależnić zestaw zależności od środowiska na którym będzie działało instalowane oprogramowanie.
Pip pozwala zainstalować wszystkie zależności z requirements.txt poleceniem:
1 | pip install -r requirements.txt |
Możemy też zrzucić wszystkie aktualnie zainstalowane biblioteki do pliku requirements.txt poleceniem:
1 | pip freeze > requirements.txt |
Czym są pliki *.whl?
Jest to format dystrybucji paczek Pythonowych, pozwala na znacznie szybsze instalowanie ich niż klasyczne instalowanie ze źródeł. Pip preferuje ten format i dopiero jeśli go nie znajdzie to będzie szukał źródeł. Oczywiście pliki takie można zainstalować ręcznie, np:
1 | pip install SomePackage-1.0-py2.py3-none-any.whl |
Pip ma wbudowane podpowiadanie składni
Tylko trzeba je sobie dokleić, tzn:
1 | pip completion --bash >> ~/.profile |
Podobna funkcjonalność istnieje dla dwóch innych powłok: fisha i zsha.
A co z rozdzieleniem zależności między środowisko deweloperskie a produkcyjne?
Jak pewnie zauważyłeś nie ma jakiegoś takiego jednego konkretnego i wygodnego sposobu by zrobić to plikiem requirements.txt. Powstały inne narzędzia takie jak np. poetry ale to już temat na inny wpis.
Tak czy siak, mam nadzieje że pokazałem coś ciekawego:)
Mateusz Mazurek
Merytoryczny artykuł!
Pozdrawiam, Mateusz.
Dzięki!
Wedle wikipedii „pip” jest bliższe „wine” jeśli chodzi jak rozwija się ten skrót:
https://en.wikipedia.org/wiki/Pip_(package_manager)
To tak żeby się czegoś przyczepić. :)
Hyhyhy :D yeah, udało się przyczepić! :D a tak serio, to oczywiście że masz rację:) oba są rekursywne :D
Nigdy nie używałem pip. Jeszcze nie doszedłem do tego poziomu znajomości Python. Myślę że managery pakietów są bardzo pomocne w tworzeniu projektu. Korzystałem trochę z npm chyba dla Angulara i trochę się w nim pogubiłem ale i tak jest to fajne narzędzie.
Fajny artykuł. Thanks :-).