Publication de nouvelles versions¶
Déploiement¶
Un rappel pour les mainteneurs sur la façon de déployer. Cette section n’est pertinente que lors de la production d’une nouvelle version pour la librairie.
Avertissement
Il est important de savoir que toute modification apportée aux fichiers trouvés dans le dossier src/xhydro
(à l’exception de src/xhydro/__init__.py
) déclenchera le flux de travail bump-version.yml
. Veillez à ne pas modifier les fichiers de ce dossier lors de la préparation d’une nouvelle version.
Créez une nouvelle branche à partir de main (par exemple release-0.2.0).
Mettez à jour le fichier CHANGELOG.rst pour remplacer la section Unreleased par la date actuelle.
Passez la version de votre branche à la version suivante (par exemple v0.1.0 -> v0.2.0) :
bump-my-version bump minor # In most cases, we will be releasing a minor version bump-my-version bump release # This will update the version strings to drop the `dev` suffix git push
Créez une pull request de votre branche vers main.
Une fois la pull request fusionnée, créez un « Release » sur GitHub. Sur la branche main, exécutez :
git tag v0.2.0 git push --tags
Cela déclenchera un workflow GitHub pour construire la nouvelle version et la télécharger sur TestPyPI. Dans le même temps, le workflow GitHub créera un brouillon de Release sur GitHub. En supposant que le flux de travail réussisse, la version finale peut ensuite être publiée sur GitHub en finalisant ce brouillon.
Pour générer les notes du Release, exécutez :
import xhydro.testing.utils as xhu print(xhu.publish_release_notes())
Cela imprimera les notes du Release (extraites du fichier CHANGELOG.rst) sur votre console Python. Copiez-collez-les dans la description de la version GitHub, en conservant uniquement les modifications de la version actuelle.
Une fois la nouvelle version publiée, le workflow publish-pypi.yml passera en mode « en attente d’approbation » sur Github Actions. Seuls les utilisateurs autorisés peuvent approuver ce workflow (des notifications seront envoyées) pour déclencher le téléchargement sur PyPI.
Avertissement
Les téléchargements vers PyPI ne peuvent jamais être écrasés. Si vous faites une erreur, vous devrez modifier la version et rééditer le package. Si le package téléchargé sur PyPI est cassé, vous devez modifier la version de GitHub pour marquer le package comme cassé, ainsi que retirer le package (marquer la version broken) sur PyPI.
Packaging¶
Lorsqu’une nouvelle version a été créée (les fonctionnalités ont été intégrées avec succès, la couverture des tests et la stabilité sont adéquates), les responsables doivent mettre à jour le package installable par pip (wheel et version source) sur PyPI ainsi que le binaire sur conda-forge.
L’approche simple¶
L’approche la plus simple du packaging pour le support général (wheel pip) nécessite que flit soit installé :
python -m pip install flit
À partir de la ligne de commande de votre distribution Linux, exécutez simplement ce qui suit depuis la branche de développement principale du clone :
# To build the packages (sources and wheel) make dist # To upload to PyPI make release
La nouvelle version sera désormais disponible via pip (pip install xhydro).
Sortie sur conda-forge¶
Première version¶
- Avant de préparer une première version sur conda-forge, nous vous suggérons fortement de consulter les liens suivants :
Afin de créer une nouvelle recette de build conda, à utiliser lors de la proposition de packages au dépôt conda-forge, nous vous suggérons fortement d’utiliser l’outil grayskull
.. code-block:: console
python -m pip install grayskull
grayskull pypi xhydro
Pour plus d’informations sur grayskull, veuillez consulter le lien suivant : https://github.com/conda/grayskull
- Avant de mettre à jour la recette principale pour conda-forge, nous faisons écho à la documentation de conda-forge et suggérons fortement d’effectuer les vérifications suivantes :
Assurez-vous que les dépendances et les versions de dépendance correspondent à celles de la version tagguée, avec des versions ouvertes ou épinglées pour les exigences de « l’hôte ».
Si possible, configurez les tests dans le build CI de conda-forge (par exemple : imports: xhydro, commands: pytest xhydro).
Versions ultérieures¶
Si la recette feedstock de conda-forge est construite à partir de PyPI, alors lorsqu’une nouvelle version est publiée sur PyPI, regro-cf-autotick-bot ouvrira automatiquement les demandes d’extraction sur le feedstock de conda-forge. Il appartient aux responsables du feedstock de conda-forge de vérifier que le package est correctement construit avant de fusionner la Pull Request avec la branche principale.
Création de sources pour un large support avec l’image manylinux¶
Avertissement
Cette section sert à créer des fichiers sources qui renvoient ou fournissent des liens vers des dépendances C/C++. Il n’est pas nécessaire d’effectuer les opérations suivantes lors de la création de packages Python purs.
Afin d’assurer une meilleure compatibilité entre les architectures, nous suggérons de créer des wheels en utilisant les images docker manylinux de PyPA (au moment de la rédaction, nous endossons l’utilisation de manylinux_2_24_x86_64).
Avec docker installé et exécuté, commencez par extraire l’image :
sudo docker pull quay.io/pypa/manylinux_2_24_x86_64
À partir du dossier source xHydro, nous pouvons entrer dans le conteneur Docker, donnant accès aux fichiers source src/xhydro en les liant à l’image en cours d’exécution :
sudo docker run --rm -ti -v $(pwd):/src/xhydro -w /src/xhydro quay.io/pypa/manylinux_2_24_x86_64 bash
Enfin, pour construire le wheel, nous l’exécutons avec le binaire Python3.9 fourni :
/opt/python/cp39-cp39m/bin/python -m build --sdist --wheel
Cela placera ensuite deux fichiers dans xhydro/dist/ (xhydro-1.2.3-py3-none-any.whlet xHydro-1.2.3.tar.gz). Nous pouvons maintenant quitter notre conteneur Docker (exit) et continuer à télécharger les fichiers sur PyPI :
python -m twine upload dist/*