diff --git a/versionner-un-code-python.qmd b/versionner-un-code-python.qmd index 8dc15152b0841884382cd816b45d5dbe140c5f0a..114d4de803cecbfa02e5f0eaa63799ed947fa721 100644 --- a/versionner-un-code-python.qmd +++ b/versionner-un-code-python.qmd @@ -484,6 +484,34 @@ des paquets Python](https://www.stella.coop/blog/00003-l-enfer-des-paquets-pytho et le fichier `setup.py` reste encore nécessaire pour un grand nombre de projets (compilation de code en C++). +## setuptools reste un backend de build possible + +L'article [Why you shouldn't invoke setup.py directly](https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html) +précise que [setuptools](https://setuptools.pypa.io/en/latest/) +est toujours maintenu et fait partie des backend utilisable (*19 oct 2021*). + +C'est l'usage de `python setup.py <commande>` qui ne doit plus être utilisé et +fait l'objet de `DeprecationWarning` ^[Ne peut pas respecter pas les +spécifications [PEP 517](https://peps.python.org/pep-0517/) et +[PEP 518](https://peps.python.org/pep-0518/) des frontends de `build`] ^[À +déterminer : quand, pourquoi et comment serait-on encore amené à utiliser un +fichier `setup.py`]. + +```{.bash} +$ python setup.py install +running install +/tmp/test-setuptools/.venv/lib/python3.10/site-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated. +!! + + ******************************************************************************** + Please avoid running ``setup.py`` directly. + Instead, use pypa/build, pypa/installer or other + standards-based tools. + + See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details. + ******************************************************************************** +``` + ## Principales étapes du packaging - Avoir le **code source** du package, typiquement le checkout d'un **tag** du @@ -723,7 +751,7 @@ elles ont pour but : - de permettre aux grosses communautés et sociétés de gérer de multiples équipes, membres, projet avec différentes permissions -Une organisation est payante pour une société et gratuite communauté. +Une organisation est payante pour une société et gratuite pour une communauté. Une organisation ne permet pas de détenir des packages "privés" ^[[PyPI Organization FAQ](https://docs.pypi.org/organization-accounts/org-acc-faq/)]. @@ -1069,7 +1097,7 @@ exclude_lines = [ `setuptools` ne gère pas les dépendances. -`setuptools` n'upload pas les distributions générées sur `PiPI`. +`setuptools` n'upload pas les distributions générées sur `PyPI`. `setuptools` ne gère pas les environnements virtuels. @@ -1107,31 +1135,75 @@ ces nouveaux standards. Et maintenant ? Il existe des librairies qui récupèrent le **tag** pour le définir dynamiquement comme numéro de version du package. -## Intégrer l'identifiant de version au package Python +## Intégrer l'identifiant de version au package Python 1/2 L'identifiant de version d'un package Python peut être spécifié statiquement dans le `pyproject.toml` ou dynamiquement ^[Voir [Declaring project metadata](https://packaging.python.org/en/latest/specifications/declaring-project-metadata/) qui remplace la [PEP 621](https://peps.python.org/pep-0621/)] +### Statiquement + En déclaration statique, l'identifiant de version est une chaîne de caractères -qui doit respecter la [PEP 440](https://peps.python.org/pep-0440/). +dans les données globales du `pyproject.toml`. -```{.toml} +```{.toml code-line-numbers="3"} [project] name = "ntt" version = "0.1.0" description = "Library for sport analysis" ``` -::: {.callout-tip title="À vérifier"} -Le numéro de version déclaré dans le `pyproject.toml` pourrait-il différer du -tag correspondant au code packagé ? -::: +### Dynamiquement -## Versioneer +Déclaration des paramètres dynamiques dans le `pyproject.toml`. -[Versioneer](https://pypi.org/project/versioneer/) is a tool for managing a -recorded version number in setuptools-based python projects. +```{.toml code-line-numbers="3"} +[project] +name = "ntt" +dynamic = ["version", "description"] +``` + +## Intégrer l'identifiant de version au package Python 2/2 + +Les modalités de récupération dépendent du backend. + +### Flit + +`Flit` récupère l'identifiant de version de la propriété `__version__` du +module et la description de la `docstring` du module. + +``` {.bash code-line-numbers="7"} +$ tree +. +├── pyproject.toml +├── README.md +├── src +│  └── ntt +│  ├── __init__.py +│  ├── ... +``` + +Ces deux métadonnées sont récupérées du fichier `src/ntt/__init__.py`. + +``` {.python} +"""Library for sport analysis""" + +__version__ = "0.1.1" +``` + + + +## À vérifier + +::: {.callout-warning} +Veillez à respecter la [PEP 440](https://peps.python.org/pep-0440/) pour +l'identifiant de version +::: + +::: {.callout-tip title="À vérifier"} +Que se passe-t-il si le numéro de version déclaré dans le `pyproject.toml` +est différent du tag positionné dans le gestionnaire de version ? +::: ## setuptools_scm @@ -1141,6 +1213,15 @@ version argument or in an SCM managed file. Le seul des trois qui semble compatible `pyproject.toml` +## Versioneer + +[Versioneer](https://pypi.org/project/versioneer/) is a tool for managing a +recorded version number in setuptools-based python projects. + +::: {.callout-warning} +Le projet qui m'a fait découvrir `Versioneer` est passé à `setuptools_scm`. +::: + ## Miniver [Miniver](https://pypi.org/project/miniver/) is a minimal versioning tool that