Ich benutze Python oft, aber ich habe jedes Mal den gleichen Code getroffen, um die Umgebung zu erstellen. Dies nimmt viel Zeit in Anspruch und die zu verwendenden Teile sind dieselben. Daher habe ich das Repository als Projektvorlage veröffentlicht, die für allgemeine Zwecke verwendet werden kann. https://github.com/odrum428/python_setup
Wenn ich ein Python-Projekt gestartet habe, habe ich immer dieselben Befehle eingegeben, z. B. um CI und Dokumente.
Es ist so, als würde man ein Projekt mit Pipenv initialisieren, CI definieren, Tests und Flusen einfügen und mit Sphinx dokumentieren.
Es hat eine Weile gedauert, bis ich sie jedes Mal eingerichtet hatte. Deshalb habe ich eine Projektvorlage erstellt, um sie für jedes Python-Projekt zu konfigurieren.
Es ist kompatibel mit Analyse, Anwendung und Modellgenerierung.
Pipenv wird für das Paket- und Umgebungsmanagement verwendet. Die folgenden Artikel sind für diese Verwaltungstools organisiert, daher hoffe ich, dass Sie darauf verweisen können. Best Practices für Python-Pakete verstehen
Derzeit ist es am besten, pipenv zu verwenden und verschiedene Einstellungen mit setup.py und setup.cfg zu verwalten. Es fühlt sich an, als hätte ich es benutzt, und es ist viel einfacher zu verwalten und zu bauen.
Die in dem diesmal erstellten Projekt verwendeten Pakete werden zusammengefasst.
Als grundlegendes Flusensystem haben wir "isort" eingeführt, um den Import von Paketen zu arrangieren, und "flake8", um den Codestil zu arrangieren. Es gibt andere Typen wie "yapf", aber wir haben das Standard-PEP8 übernommen und es zu einem bequemen "Flake8" gemacht. Hier ist der Code des Fehlerteils Es ist bereit zu tun.
Wir haben Pytest für den Test übernommen. Um ehrlich zu sein, wenn Sie pytest für Python-Tests verwenden, gibt es meines Erachtens kein Problem. Es gibt viele Dinge, die Pytest tun kann als Standard-Unittest, und es ist einfach zu handhaben.
Darüber hinaus verwendet diese Vorlage Sphinx zum Generieren von Dokumenten. Die Dokumentation wird aus dem Testcode und der Dokumentzeichenfolge generiert, die im Ordner "tests" definiert sind. Indem wir Dokumente nur aus Testfällen generieren, möchten wir Testfälle aktiv schreiben und die Dokumente bereichern. Das Thema der Dokumentation ist sphinx-rtd-theme.
CI Wir haben CI auch mit Circle CI eingeführt. Führen Sie Lint mit "isort" und "flake8" aus, um den Codestil beizubehalten, und führen Sie den Testcode mit "pytest" aus. "Tox", mit dem mehrere Versionen des Tests ausgeführt werden können, und "pytest-random", mit dem der Test zufällig erstellt wird, werden ausgeschlossen, da sie nicht für allgemeine Zwecke verwendet werden.
Darüber hinaus haben wir automatische Dokumentationsaktualisierungen implementiert. Wenn sich im Ordner "tests" ein Update befindet, aktualisiert CI das Dokument und schreibt sogar Git fest.
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
Die Dateistruktur ist unten dargestellt.
├ .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
Ich habe die Struktur leicht in Quelle, Test und Dokument unterteilt.
App-Code, maschinelles Lernen, Analysecode usw. werden auf nette Weise in src verwaltet. Schreiben Sie Testcode mit derselben Dateistruktur. Die Dokumentation wird aus dem Testcode generiert. Es ist ein Bild wie.
Ich denke, wir sollten es von hier aus entsprechend der Anwendung erweitern.
Pakete und verschiedene Einstellungen werden in setup.cfg vorgenommen. Dies vereinfacht den Code erheblich und kann wie folgt geschrieben werden:
setup.py
from setuptools import setup
setup()
Der tatsächliche Inhalt der Einstellungen wird in setup.cfg festgelegt.
[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
Registrieren Sie einfach ein neues Projekt basierend auf diesem Repository.
Dieses Mal habe ich ein Repository namens "new_project" erstellt.
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
Sie können jetzt ein neues Projekt erstellen, während Sie dieses Repository übernehmen.
3 Installieren Sie pipenv.
pip install pipenv
Als Bonus wechselt direnv automatisch zwischen virtuellen Umgebungen, daher wird empfohlen! Sie müssen die Umgebung nicht jedes Mal aktivieren. https://github.com/direnv/direnv
Ich werde es jedes Mal aktualisieren, wenn sich die Umgebung ändert. Verwenden Sie es daher, wenn Sie Probleme mit der Konfiguration haben. Ich wäre Ihnen auch dankbar, wenn Sie uns eine PR für das Repository geben könnten.
https://github.com/odrum428/python_setup