22.8.9 Moduli Python
Attualmente pacchettizziamo Python 2 e Python 3, con i nomi di variabile
Scheme python-2 e python come spiegato in Numeri di versione. Per evitare confusione e conflitti di nomi con altri linguaggi di
programmazione, sembra desiderabile che il nome di un pacchetto per un
modulo Python contenga la parola python.
Alcuni moduli sono compatibili solo con una versione di Python, altri con
entrambe. Se il pacchetto Foo è compilato con Python 3, lo chiamiamo
python-foo. Se è compilato con Python 2, lo chiamiamo
python2-foo. I pacchetti Python 2 vengono rimossi dalla
distribuzione; per favore non inviare nuovi pacchetti Python 2.
Se un progetto contiene già la parola python, la omettiamo; ad
esempio, il modulo python-dateutil è pacchettizzato con i nomi
python-dateutil e python2-dateutil. Se il nome del progetto
inizia con py (es: pytz), lo manteniamo e lo prefissiamo come
descritto sopra.
Nota: Attualmente ci sono due diversi sistemi di compilazione per i pacchetti
Python in Guix: python-build-system e
pyproject-build-system. Per molto tempo, i pacchetti Python venivano
costruiti da un file setup.py specificato informalmente. Questo ha
funzionato sorprendentemente bene, considerando il successo di Python, ma
era difficile costruire strumenti attorno ad esso. Di conseguenza, sono
emersi una serie di sistemi di compilazione alternativi e la comunità alla
fine si è stabilizzata su uno standard formale per specificare i requisiti di
compilazione. pyproject-build-system è l’implementazione di Guix di
questo standard. È considerato “sperimentale” in quanto non supporta
ancora tutti i vari backend di compilazione PEP-517, ma sei
incoraggiato a provarlo per nuovi pacchetti Python e a segnalare eventuali
problemi. Alla fine verrà deprecato e fuso in python-build-system.
22.8.9.1 Specifica delle dipendenze
Le informazioni sulle dipendenze per i pacchetti Python sono di solito
disponibili nell’albero dei sorgenti del pacchetto, con vari gradi di
precisione: nel file pyproject.toml, nel file setup.py, in
requirements.txt, o in tox.ini (quest’ultimo principalmente
per le dipendenze di test).
La tua missione, quando scrivi una ricetta per un pacchetto Python, è di
mappare queste dipendenze al tipo appropriato di “input” (vedi inputs). Sebbene l’importatore pypi faccia normalmente un
buon lavoro (vedi Invoking guix import), potresti voler controllare la
seguente lista di controllo per determinare quale dipendenza va dove.
- Attualmente pacchettizziamo Python con
setuptools e pip
installati per impostazione predefinita. Questo sta per cambiare, e gli
utenti sono incoraggiati a usare python-toolchain se desiderano un
ambiente di compilazione per Python.
guix lint avvertirà se setuptools o pip vengono
aggiunti come native-inputs perché generalmente non sono necessari.
- Le dipendenze Python richieste a runtime vanno in
propagated-inputs. Sono tipicamente definite con la parola chiave
install_requires in setup.py, o nel file
requirements.txt.
- I pacchetti Python richiesti solo in fase di compilazione — ad esempio,
quelli elencati sotto
build-system.requires in pyproject.toml
o con la parola chiave setup_requires in setup.py — o le
dipendenze solo per i test — ad esempio, quelle in tests_require o
tox.ini — vanno in native-inputs. La logica è che (1) non
hanno bisogno di essere propagate perché non sono necessarie a runtime, e
(2) in un contesto di compilazione incrociata, è l’input “nativo” che
vorremmo.
Esempi sono i framework di test pytest, mock e
nose. Naturalmente, se uno di questi pacchetti è richiesto anche a
runtime, deve andare in propagated-inputs.
- Tutto ciò che non rientra nelle categorie precedenti va in
inputs, ad
esempio programmi o librerie C richiesti per la compilazione di pacchetti
Python contenenti estensioni C.
- Se un pacchetto Python ha dipendenze opzionali (
extras_require), sta
a te decidere se aggiungerle o meno, in base al loro rapporto
utilità/sovraccarico (vedi guix size).