From 83290f629b04e7e00fc1c88948d28da9c9c91e76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7oise=20Conil?= <francoise.conil@insa-lyon.fr>
Date: Tue, 7 Nov 2023 18:42:26 +0100
Subject: [PATCH] =?UTF-8?q?Avant=20pr=C3=A9sentation=20EDP?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 versionner-un-code-python.qmd | 105 ++++++++++++++++++++++++++++++----
 1 file changed, 93 insertions(+), 12 deletions(-)

diff --git a/versionner-un-code-python.qmd b/versionner-un-code-python.qmd
index 8dc1515..114d4de 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
-- 
GitLab