J'utilise beaucoup Python, mais j'avais l'habitude de frapper le même code à chaque fois pour créer l'environnement. Cela prend beaucoup de temps et les parties à utiliser sont les mêmes, j'ai donc publié le référentiel en tant que modèle de projet pouvant être utilisé à des fins générales. https://github.com/odrum428/python_setup
Quand j'ai commencé un projet Python, j'ai toujours entré les mêmes commandes, comme autour de CI et de documents.
C'est comme initialiser un projet à l'aide de Pipenv, définir CI, effectuer des tests et des peluches, et documenter avec Sphinx.
Il m'a fallu un certain temps pour les mettre en place à chaque fois, j'ai donc créé un modèle de projet dans le but de le configurer pour n'importe quel projet Python.
Il est conçu pour être compatible avec l'analyse, l'application et la génération de modèles.
Pipenv est utilisé pour la gestion des packages et de l'environnement. Les articles suivants sont organisés pour ces outils de gestion, j'espère donc que vous pourrez vous y référer. Comprendre les meilleures pratiques autour des packages Python
À l'heure actuelle, il est préférable d'utiliser pipenv et de gérer divers paramètres avec setup.py et setup.cfg. J'ai l'impression de l'utiliser, et c'est beaucoup plus facile à gérer et à construire.
Les packages utilisés dans le projet créé cette fois sont résumés.
En tant que système de lint de base, nous avons introduit ʻisort qui organise l'importation de paquets, etc. et
flake8` qui organise le style de code.
En plus de cela, il y a aussi «yapf», etc., mais j'ai adopté le PEP8 standard et en ai fait un «flocon8» confortable. Voici le code de la partie erreur
C'est prêt à être fait.
Nous avons adopté pytest pour le test. Pour être honnête, si vous utilisez pytest pour les tests python, je pense qu'il n'y a pas de problème. Il y a beaucoup de choses que pytest peut faire par rapport à unittest standard, et c'est facile à manipuler.
De plus, ce modèle utilise Sphinx pour générer des documents.
La documentation est générée à partir du code de test et de la docstring définis dans le dossier tests
.
En générant des documents uniquement à partir de cas de test, nous visons à écrire activement des cas de test et à enrichir les documents.
Le thème de la documentation est sphinx-rtd-theme.
CI
Nous avons également introduit CI en utilisant Circle CI.
Exécutez Lint avec ʻisort et
flake8pour conserver le style de code, et exécutez le code de test avec
pytest`.
«Tox», qui permet plusieurs versions d'exécution de test, et «pytest-randomly», qui rend les tests aléatoires, sont exclus car ils ne sont pas utilisés à des fins générales.
En plus de cela, nous avons également implémenté des mises à jour automatiques de la documentation.
Lorsqu'il y a une mise à jour dans le dossier tests
, CI met à jour le document et valide même Git.
is_docs_update:
steps:
- run:
name: check tests folder is updated
command: |
if [[ ! $(git diff --diff-filter=d --name-only HEAD | grep tests/ ) = '' ]]; then
echo "build and deploy"
else
echo "no need docs update"
circleci step halt
fi
- run:
name: make rst file
command: |
pipenv run sphinx-apidoc -f -o docs/ tests/
- run:
name: make html
command: |
pipenv run sphinx-build -a ./docs ./docs/public
- run:
name: git push
command: |
git config --global user.email [email protected]
git config --global user.name odrum428
git add -A
git commit -m 'updating docs [skip ci]'
git push origin HEAD
La structure des fichiers est illustrée ci-dessous.
├ .circleci/
├ .envrc
├ .github/
├ .gitignore
├ docs/
│ ├ Makefile
│ ├ conf.py
│ ├ index.rst
│ ├ make.bat
│ ├ modules.rst
│ ├ public/
│ └ tests.rst
│
├ src/
├ tests/
├ LICENSE
├ Pipfile
├ Pipfile.lock
├ README.md
├ setup.cfg
└ setup.py
J'ai facilement divisé la structure en source, test et document.
Le code d'application, l'apprentissage automatique, le code d'analyse, etc. sont tous gérés dans src
d'une manière agréable. Écrivez le code de test avec la même structure de fichiers.
La documentation est générée à partir du code de test. C'est une image comme.
À partir de là, je pense que nous devrions l'élargir en fonction de l'application.
Les packages et divers paramètres sont définis dans setup.cfg. Cela simplifie grandement le code et peut être écrit comme suit:
setup.py
from setuptools import setup
setup()
Le contenu réel des paramètres est défini dans setup.cfg.
[metadata]
name = sample-package
version = '1.0'
auther = Keita Mizushima
auther_email = [email protected]
description = sample repogitory of python
description-file = file: README.md
url = http://example.com
license = MIT
license_file = LICENSE
[options]
install_requires=
packages = find:
[flake8]
show_source = True
max-line-length=120
max-complexity=15
Enregistrez simplement un nouveau projet basé sur ce référentiel.
Cette fois, j'ai créé un référentiel appelé nouveau_projet
.
git clone [email protected]:odrum428/python_setup.git new_poject
cd new_project
git remote set-url origin [email protected]:user_name/new_project.git
git push origin master
Vous pouvez maintenant créer un nouveau projet tout en reprenant ce référentiel.
3 Installez pipenv.
pip install pipenv
En prime, direnv bascule automatiquement entre les environnements virtuels, c'est donc recommandé! Vous n'êtes pas obligé d'activer l'environnement à chaque fois. https://github.com/direnv/direnv
Je continuerai à le mettre à jour à chaque fois que l'environnement change, veuillez donc l'utiliser si vous avez des problèmes avec la configuration. De plus, je vous serais reconnaissant de bien vouloir nous donner un PR au référentiel.
https://github.com/odrum428/python_setup
Recommended Posts