Zatím jsme tvořili programy v Pythonu tak nějak na divoko, tedy v jednom nebo více souborech bez nějakého zvláštního řádu. V této lekci se podíváme na to, jak tvořit redistribuovatelné moduly, které jdou nahrát na PyPI (veřejný seznam pythonních balíčků) a instalovat pomocí pipu.
Za příklad si vezmeme kód Ondřeje Caletky, který umožňuje určit české svátky v zadaném roce. Jako příklad je ideální, protože obsahuje jak funkce, které můžeme volat z Pythonu, tak lze volat z příkazové řádky.
Volání z příkazové řádky, pomocí příkazu python isholiday.py
nebo
python -m isholiday
, zajišťuje blok if __name__ == '__main__':
.
Toto je rychlý způsob, jak napsat modul který jde jak importovat, tak spustit.
Když nějaký modul importujeme, má v proměnné __name__
k dispozici své jméno.
„Hlavní” modul ale není importován a jeho jméno není vždy k dispozici
(např. v cat isholiday.py | python
).
Python proto __name__
„hlavního” modulu nastavuje na '__main__'
,
čehož se často využívá.
Později se podíváme na elegantnější způsob jak to zařídit; teď se vraťme zpět k balíčkování.
Základním stavebním kamenem Python balíčku je soubor setup.py
, který
obsahuje všechna potřebná metadata ve volání funkce setup()
z modulu
setuptools
.
Pojďme vytvořit jeho minimální variantu:
from setuptools import setup
setup(
name='isholiday',
version='0.1',
description='Finds Czech holiday for given year',
author='Ondřej Caletka',
author_email='ondrej@caletka.cz',
license='Public Domain',
url='https://gist.github.com/oskar456/e91ef3ff77476b0dbc4ac19875d0555e',
py_modules=['isholiday'],
)
Všimněte si, že jsme balíček pojmenovali stejně jako soubor se zdrojovým kódem. Je to dobrá konvence, ale není to technicky nutné.
Balíček můžeme zkusit nainstalovat do virtualenvu:
$ python3.6 -m venv __venv__ # (nebo jinak -- podle vašeho OS)
$ . __venv__/bin/activate # (nebo jinak -- podle vašeho OS)
(__venv__)$ python setup.py install
...
(__venv__)$ python
>>> import isholiday
>>>
(__venv__)$ python -m pip freeze
isholiday==0.1
Přes setup.py
můžeme dělat další věci, například vytvořit archiv s balíčkem:
(__venv__)$ python setup.py sdist
...
warning: sdist: standard file not found: should have one of README, README.rst, README.txt
...
Jak vidíte, setuptools
si stěžuje, že náš projekt nemá README
– soubor,
do kterého se tradičně píšou základní informace o projektu.
Můžeme jej vytvořit a uložit jako README
přímo v kořenovém adresáři projektu,
tedy tam, kde byste jej nejspíš čekali.
Czech public holiday checker...
Poté spustíme setup.py sdist
znovu:
(__venv__)$ python setup.py sdist
V adresáři dist
najdete archiv, jeho obsah můžete zkontrolovat. Měl by tam
být i soubor README
.
Skvělé, pojďme vytvořit i další speciální soubor, LICENSE
, který bude
obsahovat text licence, v tomto případě Public Domain.
Obsah najdete třeba na CC0.
Pokud ale se souborem LICENSE
vytvoříte zdrojový balíček, soubor v archivu
nebude. Je to proto, že se standardně do archivu přidávají jen některé soubory.
Další soubory lze přidat pomocí souboru MANIFEST.in
, dle dokumentace.
V našem případě bude MANIFEST.in
vypadat takto:
include LICENSE
Při dalším spuštění už setup.py
přidá i soubor LICENSE
.
To můžete zkontrolovat i ve výsledném archivu.
(__venv__)$ python setup.py sdist
...
hard linking LICENSE -> isholiday-0.1
hard linking MANIFEST.in -> isholiday-0.1
hard linking README -> isholiday-0.1
...
Hotový balíček pak můžete nainstalovat pomocí nástroje pip
.
Doporučuji to dělat v jiném virtuálním prostředí – v aktuálním už ho máte
nainstalovaný.
# v jiné konzoli, v jiném adresáři
$ python3 -m venv __venv2__
$ . __venv2__/bin/activate
(__venv2__)$ python -m pip install cesta/k/projektu/dist/isholiday-0.1.tar.gz
Processing cesta/k/projektu/dist/isholiday-0.1.tar.gz
Installing collected packages: isholiday
Running setup.py install for isholiday ... done
Successfully installed isholiday-0.1
Na chvíli se vrátíme k volání funkce setup()
a přidáme co nejvíc dalších
položek.
Jejich vysvětlení najdete v dokumentaci.
from setuptools import setup
with open('README') as f:
long_description = ''.join(f.readlines())
setup(
name='isholiday',
version='0.1',
description='Finds Czech holiday for given year',
long_description=long_description,
author='Ondřej Caletka',
author_email='ondrej@caletka.cz',
keywords='holiday,dates',
license='Public Domain',
url='https://gist.github.com/oskar456/e91ef3ff77476b0dbc4ac19875d0555e',
py_modules=['isholiday'],
classifiers=[
'Intended Audience :: Developers',
'License :: Public Domain',
'Operating System :: POSIX :: Linux',
'Programming Language :: Python',
'Programming Language :: Python :: Implementation :: CPython',
'Programming Language :: Python :: 3',
'Programming Language :: Python :: 3.5',
'Topic :: Software Development :: Libraries',
],
zip_safe=False,
)
Všimněte si několika věcí. V první řadě v long_description
vidíte, že jsme
pořád ještě v Pythonu a můžeme si ušetřit duplikaci nějakých informací pomocí
malého kousku kódu. Dalším zajímavým argumentem je classifiers
. Jsou to
v podstatě takové tagy nebo strukturované informace o balíčku.
Zásadně si je nevymýšlíme sami, ale hledáme je v
seznamu.
Tyto informace budou později vidět na PyPI a
půjde podle nich hledat.
Argument zip_safe=False
zajistí, že se modul nainstaluje do adresáře.
Setuptools totiž mají nepříjemný zlozvyk instalovat moduly jako zip
,
což komplikuje práci s datovými soubory (např. templates pro Flask).
Je proto lepší zip_safe=False
uvést.
Doteď jsme vytvářeli balíček jen z jednoho zdrojového souboru isholiday.py
.
Co ale dělat, pokud je náš projekt větší a obsahuje souborů více?
Teoreticky je možné je přidat všechny do py_modules
, ale není to dobrý nápad.
Proč to vlastně není dobrý nápad? Jednotlivé moduly ze všech nainstalovaných
balíčků by byly rozesety bez ladu a skladu mezi ostatními.
Mohl by snadno nastat konflikt v názvech, například pokud by více balíčků
mělo modul utils
.
Slušně vychovaný Pythonista dá do každého balíčku právě jeden modul,
pojmenovaný stejně jako balíček.
Raději uděláme modul ve formě složky. V našem případě soubor
isholiday.py
zatím přesuneme do isholiday/__init__.py
:
(__venv__)$ tree
.
├── isholiday
│ └── __init__.py
├── LICENSE
├── MANIFEST.in
├── README
└── setup.py
1 directory, 5 files
Soubor __init__.py
jednak značí, že adresář isholiday
je pythonní modul,
a také obsahuje kód, který se spustí při importu modulu isholiday
.
Musíme ještě mírně upravit setup.py
– místo py_modules
použijeme packages
:
diff --git a/setup.py b/setup.py
index 3a69792..6b453ab 100644
--- a/setup.py
+++ b/setup.py
@@ -11,7 +11,7 @@ setup(
keywords='holiday,dates',
license='Public Domain',
url='https://gist.github.com/oskar456/e91ef3ff77476b0dbc4ac19875d0555e',
- py_modules=['isholiday'],
+ packages=['isholiday'],
classifiers=[
'Intended Audience :: Developers',
'License :: Public Domain',
Případně, což je ještě lepší, můžeme použít find_packages()
:
from setuptools import setup, find_packages
setup(
...
packages=find_packages(),
...
)
A jaký je tedy vlastně rozdíl mezi py_modules
a packages
?
Zjednodušeně: Ten první je na soubory, ten druhý na adresáře.
Momentálně máme všechen kód přímo v __init__.py
, což sice funguje,
ale ideální to není. Dobré je mít kód v samostatných souborech a v __init__.py
pouze importovat veřejné rozhraní, tedy to, co budou z vašeho modulu importovat
jeho uživatelé.
V souboru __init__.py
by tak prakticky žádný kód kromě importů být neměl.
Přesuňte tedy obsah __init__.py
do holidays.py
a
do __init__.py
místo toho napište:
from .holidays import getholidays, isholiday
__all__ = ['getholidays', 'isholiday']
Tečka v příkazu import
není chyba: je to zkratka pro aktuální modul.
Můžeme psát i from isholiday.holidays import ...
,
což ale trochu ztěžuje případné přejmenování modulu.
Ono __all__
pak explicitně definuje rozhraní modulu. Například s původním
modulem šlo provést from isholiday import datetime
, ale asi by nikdo
nečekal, že tahle možnost bude nutně zachována i v příštích verzích knihovny.
Seznamem __all__
dáte najevo, že tyhle funkce nejsou jen „náhodné importy“,
a zároveň tím zamezíte různým varováním o
importovaném ale nevyužitém modulu, které může hlásit vaše IDE nebo linter.
Python samotný pak __all__
používá jako seznam proměnných importovaných
přes from isholiday import *
Tento způsob importu nevidíme rádi,
protože znepřehledňuje kód, to ale neznamená, že to musíme uživatelům
naší knihovny znepříjemňovat (např. pro interaktivní režim).
Pokusíme-li se teď program spustit pomocí python -m isholiday
,
narazíme na problém: na rozdíl od souboru se složka s kódem takto spustit nedá:
$ python -m isholiday
python: No module named isholiday.__main__; 'isholiday' is a package and cannot be directly executed
Namísto spuštění souboru (typicky s blokem if __name__ == '__main__':
) totiž
Python v tomto případě hledá soubor pojmenovaný __main__.py
a spustí ten.
Soubor __main__.py
není určený k tomu, aby se z něho importovalo, proto
by měl obsahovat co nejméně kódu – ideálně jen volání funkce, která je
definovaná jinde. Vytvořte proto __main__.py
s následujícím obsahem:
from .holidays import main
main()
a v holidays.py
zaměňte if __name__ == '__main__':
za def main():
.
Skript teď bude možné použít pomocí python -m isholiday
.
Bude to fungovat i tehdy, když vytvoříte balíček (python setup.py sdist
)
a nainstalujete ho v jiném virtuálním prostředí.
Pokud chcete, aby váš modul umožňoval spouštění přímo z příkazové řádky,
bez python -m
, měli byste použít entrypoints.
K tomu je potřeba přidat do volání setup
v setup.py
příslušný argument:
setup(
...
entry_points={
'console_scripts': [
'isholiday_demo = isholiday.holidays:main',
],
},
)
isholiday_demo
je jméno entrypointu, tedy příkazu pro příkazovou řádku.
isholiday.holidays:main
je pak cesta k funkci ve tvaru modul:funkce
;
funkce může být v modulu definovaná nebo importovaná.
Skript bude možné použít, je-li aktivní prostředí, kde je nainstalován, jen zadáním jména entrypointu:
(__venv__)$ python setup.py sdist
# v jiné konzoli, v jiném virtuálním prostředí
(__venv2__)$ python -m pip install --upgrade cesta/k/projektu/dist/isholiday-0.1.tar.gz
(__venv2__)$ isholiday_demo
...
Mon Mar 28 00:00:00 2016 True
Tue Mar 28 00:00:00 2017 False
Fri Apr 14 00:00:00 2017 True
Balíčky na PyPI mohou záviset na dalších balíčkách. V případě isholiday
to
potřeba není, ale v úlohách z minulých cvičení ano.
Existuje několik úrovní závislostí, ve většině případů si
vystačíte s argumentem install_requires
.
Balíček, který závisí na knihovnách Flask
(jakékoli verze) a
click
(verze 6 a vyšší) by v setup.py
měl mít:
setup(
...
install_requires=['Flask', 'click>=6'],
)
Kromě závislostí v setup.py
se u pythonních projektů často setkáme se souborem
requirements.txt
, který obsahuje přesné verze všech závislostí, včetně
tranzitivních – t.j. závisí-li náš balíček na Flask
a Flask
na Jinja2
,
najdeme v requirements.txt
mimojiné řádky:
Flask==0.11.1
Jinja2==2.8
Tento soubor se používá, když je potřeba přesně replikovat prostředí, kde
program běží, například mezi testovacím strojem a produkčním nasazením
webové aplikace.
Tento soubor se dá vygenerovat z aktuálního prostředí zadáním
python -m pip freeze > requirements.txt
a balíčky v něm se dají nainstalovat
pomocí python -m pip install -r requirements.txt
.
My ho používat nebudeme, vystačíme si s volnější specifikací závislostí
v setup.py
.
Balíček jde zaregistrovat a nahrát na PyPI. Původně k tomu sloužily příkazy
setup.py
register
a upload
, ale tyto příkazy používají HTTP, což není
bezpečné. Prototo je lepší použít program twine
(instalovatelný přes pip),
který používá HTTPS.
Budete si potřebovat zařídit
účet na PyPI,
účet na testovací PyPI
a vytvořit konfigurační soubor ~/.pypirc
:
[distutils]
index-servers=
pypi
testpypi
[pypi]
username = <your user name goes here>
password = <your password goes here>
[testpypi]
repository = https://test.pypi.org/legacy/
username = <your user name goes here>
password = <your password goes here>
Hesla můžete vynechat, pokud je budete chtít pokaždé zadávat.
Používáte-li Windows, je potřeba nastavit proměnnou prostředí HOME
na adresář
se souborem .pypirc
, např:
> set HOME=C:\cesta\k\nastaveni
Registrace projektu a nahrání na testovací PyPI se provádí pomocí příkazu
upload
: ten projekt zaregistrueje (pokud to jde) a nahraje samotný balíček:
(__venv__)$ twine upload -r testpypi dist/isholiday-0.1.tar.gz
Uploading distributions to https://test.pypi.org/legacy/
Uploading isholiday-0.1.tar.gz
[================================] 8379/8379 - 00:00:02
První nahrání se zdaří, jen pokud jméno projektu již není zabrané. Další nahrávání je povoleno jen vám, případně uživatelům, kterým to povlíte přes webové rozhraní. Po úspěšném nahrání lze nahrávat další verze modulu, ale musí být novější než ta, co už na PyPI je. Nejde tedy jednou nahraný modul přepsat.
Svůj balíček najdete na https://test.pypi.org/project/<název_balíčku>/
.
Pro nahrání na opravdovou PyPI stačí vynechat -r testpypi
.
Zabírat jména na opravdové PyPI jen tak není hezké vůči ostatním Pythonistům;
registrujte tedy prosím jen moduly, které budou nějak pro ostatní užitečné.
Projekt nahraný na PyPI by mělo jít nainstalovat pomocí pipu. V případě použití ostré verze PyPI stačí k instalaci zadat název balíčku:
(__venv__)$ python -m pip install <název_balíčku>
Pokud však použijeme testovací PyPI, je nutné pipu říct, aby balíček hledal tam. Postup uvedený v dokumentaci není v tomto případě nejvhodnější, protože z testovací PyPI vezme jak náš balíček, tak i případné závislosti, které mohou být zastaralé, rozbité či jinak škodlivé.
Lepší by bylo, kdyby pip nainstaloval závislosti z ostré PyPI a na testovací
hledal jen náš projekt. Toho se dá docílit přepínačem --extra-index-url
.
(__venv__)$ python -m pip install --extra-index-url https://test.pypi.org/pypi <název_balíčku>
V tomto případě pip nejdřív prohledá ostrou PyPI, a pokud nenajde požadovaný balíček, použije testovací PyPI. Zde je potřeba dávat pozor na název projektu, protože případné konflikty mezi ostrou a testovací PyPI se nekontrolují. Pokud tedy máme projekt na testovací PyPI a na ostré existuje projekt se stejným názvem, nainstaluje se ten z ostré verze.
V případě, že tento problém nastane, je možné ho částečně obejít specifikací verze instalovaného balíčku:
(__venv__)$ python -m pip install --extra-index-url https://test.pypi.org/pypi <název_balíčku>==0.3
Pokud u duplicitního projektu na ostré PyPI neexistuje požadovaná verze, nainstaluje se náš projekt z testovací PyPI.
Jiná možnost je zadat přímo cestu k archivu s balíčkem místo jeho názvu. Zde pak na umístění balíčku ani verzi nezáleží:
(__venv__)$ python -m pip install https://test-files.pythonhosted.org/packages/.../<název_balíčku>-0.3.tar.gz
Archiv se dá najít na informační stránce o našem projektu na PyPI.
Některé balíčky kromě samotného kódu potřebují i datové soubory.
Například aplikace ve Flasku potřebují templates.
Taková data se dají přidat parametrem package_data
:
setup(...,
packages=['hello_flask'],
...
package_data={'hello_flask': ['templates/*.html']},
)
Další informace jsou odkázané v dokumentaci.
Zatím jsme se zabývali jen zdrojovými balíčky sdist
(source distribution).
Existují ale i balíčky „zkompilované” – bdist
(binary distribution).
Když se instaluje zdrojový balíček, vykonává se kód ze souboru setup.py
.
Binární balíček se místo toho jen rozbalí na patřičné místo.
Z historických důvodů existuje několik různých druhů binárních distribucí,
v současné době je ale důležitá pouze možnost bdist_wheel
:
(__venv__)$ python setup.py bdist_wheel
Výsledek je v souboru dist/*.whl
.
Pokud vám příkaz nefunguje, nainstalujte balík wheel
.
Obsah wheelu můžete prozkoumat, je to obyčejný ZIP.
Naše programy jsou zatím platformně nezávislé a ve wheelu,
i když se jmenuje binární, žádné binární soubory nejsou.
To se ale změní, až se budeme zabývat tvorbou modulů v jazyce C:
sdist
pak obsahuje zdrojové soubory a bdist_wheel
zkompilované moduly.
Potom je dobré distribuovat oba dva – každý má své výhody:
Proces vydání složitějšího softwaru pak může vypadat takto:
(__venv__)$ rm dist/*
(__venv__)$ python setup.py sdist bdist_wheel
[... kontrola vytvořených balíčků v „čistém“ virtualenvu ...]
(__venv__)$ python -m twine upload dist/*
K balíčkování existuje obsáhlá dokumentace. Budete-li chtít dělat něco, co v tomto kurzu není, podívejte se tam!