Nous avons résumé les étapes nécessaires pour créer et publier un package Python. Nous prévoyons d'ajouter des liens vers des documents de référence à une date ultérieure ou de créer un autre article pour une utilisation et des détails spécifiques de l'outil.
Je publierai le package vers février 2020! J'ai pensé, mais j'ai eu du mal à ne pas savoir par quoi commencer. Nous avons résumé les connaissances acquises au cours du processus de développement, nous espérons donc qu'elles seront utiles à ceux qui envisagent de les diffuser à l'avenir!
Paquets cibles:
Points à considérer:
outil:
--Carte mentale --Outil de création de contour: WorkFlowy
Lors de la création d'un environnement de développement sur votre PC local, vous devez mettre en place un mécanisme pour publier le code créé. De plus, en utilisant Git pour enregistrer l'historique des modifications à tout moment, vous serez en mesure de saisir efficacement l'état du développement.
Créez un référentiel distant pour le développement sur GitHub et clonez-le dans votre environnement local pour le développement. Lorsque vous avez terminé, validez dans votre environnement local et poussez vers le référentiel distant.
Si vous utilisez Windows 10, nous vous recommandons d'utiliser WSL (sous-système Windows pour Linux) ou WSL2 si possible.
Préparez un éditeur ou un IDE (environnement de développement intégré) dans votre environnement local.
Visual Studio Code (VScode) est recommandé. De nombreux plug-ins sont disponibles pour faciliter la gestion des opérations Git.
pipenv et la poésie semblent prometteurs. J'utilise pipenv, mais j'envisage de migrer vers la poésie car j'obtiens des erreurs fréquentes et lent. (Il n'a pas été vérifié si la poésie est plus rapide ...)
Il semble y avoir différentes façons de penser à l'utilisation des branches et au moment de la fusion, comme Git Flow et GitHub Flow. Si vous développez au niveau individuel ou de quelques personnes, nous vous recommandons d'utiliser le simple Gitlab Flow.
Il est également utile d'utiliser la fonction issue de GitHub comme espace de liste de tâches et de discussion. Étant donné que des numéros individuels sont attribués aux problèmes et aux demandes d'extraction telles que # 1, soulevez un problème avec le problème # 1, travaillez sur la branche ʻissue1` en fonction du numéro de problème, et par défaut par demande d'extraction. La procédure consiste à le fusionner dans une branche.
Versioning En tant que flux majeur, je pense qu'il serait pratique de développer en deux parties, la «version de développement (gérée par GitHub)» et la «version stable (gérée par PyPI)». La version de développement est créée selon le flux de développement décrit ci-dessus.
Il semblait y avoir peu de dénomination fixe de la version de développement. Dans mon cas, je donne une version de développement juste après la fusion et la résolution du problème.
(Exemple) Lorsque le numéro 2 est fermé en raison d'un correctif de bogue: 2.0.1-alpha.new.1 → 2.0.1-beta.new.1.fix.2
De plus, si un grand nombre de problèmes sont résolus ou si vous avez besoin de corriger de toute urgence un bogue dans la version stable, suivez le Versionnage sémantique pour la version stable. Veuillez augmenter la version.
Nous avons résumé les éléments qui nécessitent une attention lors du codage, tels que la structure des dossiers.
Si vous créez une description en une ligne du package en anglais et que vous sélectionnez un alphabet pour en faire le nom du package, vous n'aurez pas à vous inquiéter trop. Je me fiche de l'ordre de sélection de l'alphabet (rires)
Exemple: package Python pour ** COV ** ID-19 anal ** y ** sis avec ** ph ** dépendant de l'ase ** SIR ** - modèles ODE dérivés = ** CovsirPhy **
Vous pouvez également utiliser la recherche Google pour éviter le chevauchement avec d'autres noms de service.
Je pense qu'il sera difficile de le changer plus tard car cela causera beaucoup de problèmes tels que le changement de méthode d'installation.
Si vous utilisez la poésie, vous devrez l'écrire dans un fichier séparé, mais si vous utilisez pipenv pour gérer les packages dépendants, créez les fichiers setup.py et setup.cfg en haut du référentiel. S'il vous plaît.
setup.py
from setuptools import setup
setup()
setup.cfg
[metadata]
name =nom du paquet
version = attr:nom du paquet.__version__.__version__
url =URL telle que le référentiel
author =Nom de l'auteur
author_email =adresse mail
license = Apache License 2.0
license_file = LICENSE
description =Description en une ligne du package
long_description = file: README.rst
keywords =mot-clé
classifiers =
Development Status :: 5 - Production/Stable
License :: OSI Approved :: Apache Software License
Programming Language :: Python :: 3.7
Programming Language :: Python :: 3.8
[options]
packages = find:
install_requires =
#Nom du package dépendant
numpy
matplotlib
Veuillez remplacer la partie écrite en japonais et le nom de la licence le cas échéant! De plus, si vous ajoutez un package dépendant, vous devrez l'ajouter à tout moment dans le champ "install_requires".
Créez un dossier avec le nom du package (ou dossier src) en haut du référentiel. Tout d'abord, créez des fichiers vides __version __. Py et __init __. Py dedans.
Et décidons de la structure des dossiers (structure du module). Faites attention à l'importation circulaire [^ 1]. Il arrive que src / A / a1.py soit importé par src / B / b1.py et que src / B / b2.py soit importé par src / A / a2.py. Il ne faut pas. Cela ne provoque pas d'erreur dans l'environnement de développement, mais il semble qu'une erreur puisse se produire lors de l'installation de la version stable par pip, j'ai donc eu du mal. J'ai augmenté le numéro de lot stable deux fois juste pour ce correctif.
[^ 1]: Que se passe-t-il lorsque vous importez de manière cyclique avec Python
La gestion avec src / __ version __. Py au lieu de setup.cfg est pratique car vous pouvez obtenir et afficher le numéro de version même dans le paquet. Dans l'exemple ci-dessus de setup.cfg, ce fichier est appelé par version = attr: nom du package .__ version __.__ version __.
__version__.py
__version__ = "0.1.0"
Ce qui suit est le cas de la création d'une fonction appelée line_plot dans src / util / plotting.py. En écrivant from src.util.plotting import line_plot, vous pouvez appeler from src import line_plot au lieu de from src.util.plotting import line_plot lorsque vous installez pip.
__init__.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# version
from src.__version__ import __version__
# util
from src.util.plotting import line_plot
def get_version():
"""
Return the version number,comme le nom du package v0.0.0
"""
return f"Nom du package v{__version__}"
__all__ = ["line_plot"]
En écrivant __all__ = [" line_plot "], vous pouvez éviter la confirmation de correction des outils de formatage de code tels que pylint (bien que vous puissiez changer le paramètre de pylint pour masquer la confirmation de correction). De plus, vous pouvez utiliser line_plot simplement en faisant à partir de src import *, mais ʻimport * `est obsolète ...
Si vous avez le code minimum, le fichier d'installation et le numéro de version, vous pouvez enregistrer le package dans test-PyPI ou PyPI!
Il est inévitable que des bugs surviennent (cela peut aussi être un moteur de développement), mais nous souhaitons éliminer au maximum les bugs avant de publier afin de ne pas en user l'esprit. Je ne pense pas qu'il soit nécessaire d'écrire des tests à 100% exactement, mais je pense que les développeurs sont tenus d'écrire du code de test et de vérifier l'opération à l'avance, du moins pour la méthode que les utilisateurs utilisent principalement.
Il existe plusieurs packages de création / exécution de code de test connus tels que ʻunittest, pytest, doctest, nose`. J'utilise personnellement «pytest».
Fondamentalement, il s'agit de "développement local et test local", mais si le nombre de codes de test augmente et que cela prend plus de 10 minutes pour un test, il peut ne pas être possible de le gérer localement.
Dans ce cas, envisagez d'exécuter le test automatiquement à l'aide de l'outil d'intégration continue (CI). Les actions GitHub (créées à partir de l'écran du référentiel GitHub), Travis CI, Semaphore, etc. sont connues. S'il s'agit d'un projet Open Source, vous pouvez l'utiliser gratuitement dans une certaine mesure.
Sémaphore m'est redevable. Il n'y a pas beaucoup d'articles en japonais, donc j'ai l'intention d'écrire un article à une date ultérieure.
Dans le cas d'un package pour la science des données (téléchargement d'un fichier CSV à partir d'une base de données / analyse de données), les arguments d'entrée de chaque fonction et de chaque classe changent à chaque instant, et le développeur prédit et teste toutes les valeurs d'entrée. C'est difficile à faire. Je pense que les trois modèles suivants peuvent être considérés comme des solutions.
--Vérifiez le type de données d'entrée (ʻis instance (data, pandas.DataFrame) , set (data.columns) .issubset (fields) `)
--Vérifiez le type de données de sortie
--Créez des données d'entrée virtuelles et vérifiez si les données de sortie sont comme prévu
La documentation est essentielle pour transmettre et promouvoir comment utiliser et utiliser le package.
Tout d'abord, écrivez la docstring pour chaque fonction / classe / méthode Python (de préférence en anglais). Je pense qu'il vaut mieux écrire en parallèle lors de la mise en œuvre du code.
Il existe des notations de style reStructuredText, de style Google et de style numpy, mais le style Google, qui est moins susceptible d'être redondant de haut en bas, est recommandé. (Lorsque j'utilisais Python uniquement pour le projet Private, je l'ai écrit dans mon propre style similaire au style Numpy, mais je suis passé au style Google.)
Si vous souhaitez documenter l'exemple d'utilisation, l'expression Jupyter Notebook (.ipynb) peut être utile. Vous pouvez afficher la description, le code et les résultats ensemble.
Exemple: CovsirPhy: Usage (version la plus rapide)
Vous pouvez utiliser pandoc ou sphinx (api-doc) pour convertir semi-automatiquement les fichiers docstring et .ipynb au format markdown / html. Je vais l'omettre dans cet article car ce sera long, mais c'est facile car vous pouvez créer une page d'accueil uniquement avec Python sans connaître les détails de HTML et CSS.
Utilisez GitHub Pages pour mettre à jour le fichier html du référentiel GitHub de temps en temps. Vous pouvez publier et mettre à jour le document par vous-même.
J'ai omis les détails et me suis précipité, mais merci pour la navigation. S'il vous plaît laissez-nous savoir s'il y a un excès ou une carence ou d'autres méthodes. Il sera mis à jour de temps à autre.
Je vous remercie pour votre travail acharné!
Recommended Posts