Dies ist ein kleines Handbuch / eine Geschichte darüber, wie man ein "perfektes" pypi-Paket für Python erstellt, das jeder mit dem geliebten Befehl installieren kann:
pip install my-perfect-package
Es richtet sich an Anfänger, aber ich fordere Profis auf, ihre Meinung darüber zu äußern, wie das "perfekte" Paket verbessert werden kann. Deshalb bitte ich um Katze.
Was bedeutet ein "ideales" Paket?
Ich gehe von folgenden Voraussetzungen aus:
- Open Source auf Github;
Jeder sollte in der Lage sein, zur Entwicklung beizutragen und dem Autor zu danken. - Unterstützung für alle aktuellen / beliebten Versionen von Python (2.7, 3.5, 3.6, 3.7, 3.8);
Pythons sind anders und schreiben irgendwo noch aktiv auf 2.7. - 100% ige Abdeckung mit Unit-Tests;
Unit-Tests verbessern die Architektur und automatisieren Regressionsprüfungen.
Ein Abzeichen mit einer geschätzten Nummer wirft die FAQ auf und setzt die Messlatte für andere . - Verwendung von CI:
Automatische Prüfungen sind sehr bequem! Und ein paar coole Abzeichen
- Ausführen von Unit-Tests auf allen Plattformen und auf allen Python-Versionen;
Glauben Sie nicht denjenigen, die behaupten, dass Python und installierte Pakete plattformübergreifend sind , da Sie immer auf einen Fehler stoßen können. - Style Code Check;
Ein einheitlicher Stil verbessert die Lesbarkeit und verringert die Anzahl leerer Diskussionen in einer Überprüfung. - Statischer Code-Analysator;
Automatische Suche nach Fehlern im Code? Gib mir zwei!
- Aktuelle Dokumentation;
Beispiele für die Arbeit mit dem Paket, die Beschreibung von Methoden / Klassen und die Analyse typischer Fehler - dokumentierte Erfahrungen reduzieren die Einstiegsschwelle für Anfänger. - Plattformübergreifende Entwicklung;
Leider ist es schwierig, einen persönlichen Beitrag zu Projekten zu leisten, nur weil der Entwickler die Tools für Unix geschärft hat. Ich habe zum Beispiel Bash-Skripte für die Assemblierung verwendet. - Das Paket ist nützlich und macht die Welt zu einem besseren Ort.
Eine schwierige Anforderung, da nach der Anzahl der Pakete in pypi (~ 210k) Entwickler wilde Altruisten sind und bereits viel geschrieben wurde.
Wo soll ich anfangen?
Da es keine guten Ideen gab, entschied ich mich für ein abgedroschenes und sehr beliebtes Thema - die Arbeit mit Zahlensystemen. Die erste Version sollte in der Lage sein, Zahlen ins Römische und umgekehrt zu übersetzen. Denn das Handbuch ist komplizierter und nicht notwendig. Oh ja, das Wichtigste ist der Name: numsys - als Entschlüsselung von Zahlensystemen. Zahlensystem-py .
Wie teste ich?
Ich nahm python3.7 und schrieb zuerst Tests mit Funktionsstubs (wir sind alle TDDs ) unter Verwendung des Standardmoduls unittests .
Ich mache folgende Projektstruktur:
src/ numeral-system/ __init__.py roman.py tests __init__.py test_roman.py
Ich lege keine Tests in das Paket, also trenne ich mich Spreu . Anfangs habe src/ den Ordner " src/ " nicht erstellt, aber die Weiterentwicklung hat gezeigt, dass die Bedienung für mich bequemer ist. Dies ist daher nach Belieben nicht erforderlich.
Ich habe mich für pytest zum Starten entschieden - es kann perfekt mit Tests aus dem Standardmodul arbeiten. Es mag ein bisschen unlogisch aussehen, aber das Standardmodul für Tests ist für mich es scheint schien ein bisschen komfortabler. Jetzt würde ich empfehlen, den pytest-Schreibstil zu verwenden.
Sie sagen jedoch, dass das pytest (wie alle anderen Abhängigkeiten) in pytest keine sehr kluge Idee ist ...
Wie man Abhängigkeiten verwaltet
Es können nur virtualenv und requirements.txt verwendet werden. Sie können progressiv sein und Gedichte verwenden . Vielleicht werde ich tox verwenden - ein Tool zur Vereinfachung der Automatisierung und des Testens, mit dem ich auch Abhängigkeiten verwalten kann.
Ich erstelle eine einfache tox.ini-Konfiguration und installiere pytest :
[tox] envlist = py37 ; , python3.7 [testenv] ; deps = `deps` , . -r requirements.txt ; -r requirements-test.txt ; commands = pytest ;
Anfangs habe ich die Abhängigkeiten explizit angegeben, aber die Praxis der Integration mit Diensten von Drittanbietern hat gezeigt, dass es immer noch am besten ist, die Abhängigkeiten in der Datei requirements.txt speichern.
Es entsteht ein sehr subtiler Moment. Fix die aktuelle Version zum Zeitpunkt der Entwicklung oder immer die neueste?
Wenn Sie ein Commit durchführen, kann es während der Installation zu Konflikten zwischen Paketen kommen, da unterschiedliche Versionen der Abhängigkeiten verwendet werden. Wenn Sie kein Commit ausführen, funktioniert das Paket möglicherweise plötzlich nicht mehr. Die letztere Situation ist für die Endprodukte sehr unangenehm, wenn alle Builds in einer Nacht aufgrund einer geringfügigen Aktualisierung der impliziten Abhängigkeit rot werden können. Und laut Murphys Gesetz wird dies am Veröffentlichungstag geschehen.
Deshalb habe ich für mich eine Regel entwickelt:
- Korrigieren Sie immer die Version für die Endprodukte, da die Verantwortung für die zu verwendenden Versionen liegt.
- Korrigieren Sie nicht die für installierte Pakete verwendete Version. Oder beschränken Sie es auf einen Bereich, wenn die Paketfunktionalität dies erfordert.
Was weiter?
Ich schreibe Tests!
Ich fülle den Funktionsumfang aus, füge Kommentare hinzu und lasse die Tests korrekt laufen.
An diesem Punkt hören die meisten Entwickler normalerweise auf (ich glaube immer noch, dass jeder Tests schreibt =), veröffentlichen das Paket und hacken Bugs. Aber ich gehe weiter und in das Kaninchenloch springen .
Wie arbeite ich mit verschiedenen Versionen von Python?
In der tox Konfiguration spezifiziere tox den Start von Tests für alle interessanten Versionen von Python:
[tox] envlist = py{27,35,36,37,38}
Mit pyenv liefere ich mir die erforderlichen Versionen vor Ort, damit tox sie finden und Testumgebungen erstellen kann.
Wo sind die geschätzten 100%?
Ich füge ein Maß für die Abdeckung des Codes hinzu - dafür gibt es ein hervorragendes Abdeckungspaket und nicht weniger eine hervorragende Integration mit pytest - pytest-cov .
requirements-test.txt sieht jetzt so aus:
six=1.13.0 pytest=4.6.7 pytest-cov=2.8.1 parameterized=0.7.1
Gemäß der obigen Regel behebe ich Versionen von Paketen, die zum Ausführen von Tests verwendet werden.
Ich ändere den Testlaufbefehl:
deps = -r requirements.txt -r requirements-test.txt commands = pytest \ --cov=src/ \ --cov-config="{toxinidir}/tox.ini" \ --cov-append
Ich sammle Abdeckungsstatistiken für den gesamten Code aus dem Ordner " src/ " - dem Paket selbst ( numeral_system / ) und dem Testcode ( tests / ). Ich möchte nicht, dass die Tests selbst nicht ausführbare Teile enthalten.
--cov-append Befehl --cov-append alle gesammelten Statistiken für jeden Aufruf unter einer anderen Python-Version zu einer zusammen, da die Abdeckung für die zweite und dritte Python-Version unterschiedlich sein kann (hi versionsabhängiger Code und Modul 6 !), Aber insgesamt 100 ergeben % Ein einfaches Beispiel:
if sys.version_info > (3, 0):
Fügen Sie eine neue Umgebung hinzu, um einen Abdeckungsbericht zu erstellen.
[testenv:coverage_report] deps = coverage commands = coverage html ; , coverage report --include="src/*" --fail-under=100 -m ; 100%
Und ich füge der Liste der Umgebungen hinzu, nachdem ich Tests für alle Versionen von Python ausgeführt habe.
[tox] envlist = py{27,35,36,37,38} coverage_report
Nach dem Ausführen des Befehls tox sollte der Ordner tox , der die Datei index.html mit einem schönen Bericht enthält, im Projektstamm tox .
Für das begehrte Abzeichen integriere ich 100% in den Codecov- Dienst, der selbst bereits in github integriert github und es Ihnen ermöglicht, den Verlauf von Änderungen der Codeabdeckung anzuzeigen. Dazu müssen Sie dort natürlich einen Account anlegen.
Die endgültige Startumgebung sieht wie folgt aus:
[testenv:coverage_report] deps = coverage==5.0.2 codecov==2.0.15 commands = coverage html coverage report --include="src/*" --fail-under=100 -m coverage xml codecov -f coverage.xml --token=2455dcfa-f9fc-4b3a-b94d-9765afe87f0f ; codecov,
Jetzt muss nur noch ein Link zum Badge in README.rst :
|Code Coverage| .. |Code Coverage| image:: https://codecov.io/gh/zifter/numeral-system-py/branch/master/graph/badge.svg :target: https://codecov.io/gh/zifter/numeral-system-py
Viele Analysegeräte existieren nicht, da sie sich größtenteils ergänzen. Daher werde ich gängige statische Analysegeräte einbinden , die die Einhaltung von PEP8 überprüfen , mögliche Probleme finden und behebe alle Fehler Formatieren Sie den Code einheitlich.
Sie sollten sofort überlegen, wo Sie die Parameter für die Feinabstimmung der Analysegeräte festlegen müssen. Zu diesem tox.ini können Sie die Datei tox.ini , setup.cfg , eine einzelne benutzerdefinierte Datei oder bestimmte Dateien für Analysegeräte verwenden. Ich habe mich für die tox.ini Verwendung von tox.ini entschieden, da Sie tox.ini für zukünftige Projekte kopieren können.
isort
isort ist ein Dienstprogramm zum Formatieren von Importen.
Ich erstelle die folgende Umgebung, um isort im Code-Format-Modus auszuführen.
[testenv:isort] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort -y -sp={toxinidir}/tox.ini
Leider kann isort keinen Ordner zum Formatieren angeben. Daher müssen Sie das Startverzeichnis über changedir und den Pfad zur Datei mit den Einstellungen -sp={toxinidir}/tox.ini . Der Schalter -y wird benötigt, um den interaktiven Modus zu deaktivieren.
Für die Ausführung von Tests benötigen Sie einen Überprüfungsmodus - hierfür gibt es ein --check-only Flag:
[testenv:isort-check] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort --check-only -sp={toxinidir}/tox.ini
schwarz
Als nächstes integriere ich mit dem schwarzen Code-Formatierer. Ich mache es analog zu isort :
[testenv:black] deps = black==19.10b0 commands = black src/ [testenv:black-check] deps = black==19.10b0 commands = black --check src/
Alles funktioniert gut, aber es gibt einen Konflikt mit isort - es gibt einen Unterschied in der Formatierung von Importen .
In einem der Kommentare habe ich eine minimal kompatible isort Einstellung gefunden, die ich verwendet habe:
[isort] multi_line_output=3 include_trailing_comma=True force_grid_wrap=0 use_parentheses=True line_length=88
flake8
Als nächstes integriere ich mit Flake8 statischen Analysatoren.
[testenv:flake8-check] deps = flake8==3.7.9 commands = flake8 --config=tox.ini src/
Es gibt wieder Probleme bei der Integration mit black . Wir müssen eine Feinabstimmung hinzufügen, die in der Tat von black selbst empfohlen wird:
[flake8] max-line-length=88 ignore=E203
Leider hat es beim ersten Mal nicht funktioniert. Fiel mit Fehler E231 missing whitespace after ',' , musste ich diesen Fehler hinzufügen, um zu ignorieren:
[flake8] max-line-length=88 ignore=E203,E231
Pylint
Integration mit statischen Code- Analysatoren von Pylint
[testenv:pylint-check] deps = {[testenv]deps} # pylint , pylint==2.4.4 commands = pylint --rcfile=tox.ini src/
Ich stoße sofort auf merkwürdige Einschränkungen - Funktionsnamen mit 30 Zeichen (ja, ich schreibe sehr lange Namen von Testmethoden) und Warnungen für das Vorhandensein von TODO im Code.
Ich muss ein paar Ausnahmen hinzufügen:
[MESSAGES CONTROL] disable=fixme,invalid-name
Der unangenehme Moment ist auch, dass pylint Entwickler pylint bereits vergraben python2.7 und kein Paket mehr dafür entwickeln. Daher sollten die Prüfungen für das aktuelle Paket für python3.7 .
Fügen Sie der Konfiguration die entsprechende Zeile hinzu:
[tox] envlist = isort-check black-check flake8-check pylint-check py{27,35,36,37,38} coverage_report basepython = python3.7
Dies ist auch wichtig, um Tests auf verschiedenen Plattformen auszuführen, da die Standardversion von Python in CI-Systemen unterschiedlich ist.
Was ist los mit CI?
Förderer
Integration mit Appveyor - CI für Windows. Die anfängliche Einrichtung ist einfach - alles kann über die Benutzeroberfläche erfolgen. Laden Sie dann die yaml-Datei herunter und übertragen Sie sie in das Repository.
version: 0.0.{build} install: - cmd: >- C:\\Python37\\python -m pip install --upgrade pip C:\\Python37\\pip install tox build: off test_script: - cmd: C:\\Python37\\tox
Hier python3.7 ich explizit die Version von python3.7 , da python2.7 verwendet wird (und tox auch diese Version, obwohl ich python3.7 explizit angegeben python3.7 ).
Der Link zum Badge wird wie gewohnt zu README.rst hinzugefügt
|Build status Appveyor| .. |Build status Appveyor| image:: https://ci.appveyor.com/api/projects/status/github/zifter/numeral-system-py?branch=master&svg=true :target: https://ci.appveyor.com/project/zifter/numeral-system-py
Travis ci
Danach integriere ich mit Travis CI - CI unter Linux (und unter MacOS mit Windows, aber Python builds are not available on the macOS and Windows environments unter MacOS Python builds are not available on the macOS and Windows environments . Das Setup ist etwas komplizierter, da die Konfigurationsdatei direkt aus dem Repository verwendet wird. Einige Test- und Fehleriterationen - die konfiguration ist fertig, ich quetsche ein schönes commit ein und die zusammenführungsanforderung ist fertig.
language: python python: 3.8 # dist: xenial # required for Python 3.7 (travis-ci/travis-ci#9069) sudo: required # required for Python 3.7 (travis-ci/travis-ci#9069) addons: apt: sources: - deadsnakes packages: - python3.5 - python3.6 - python3.7 - pypy install: - pip install tox script: - tox
( Rhetorische Frage: Und warum mögen CI-Projekte das Yaml-Format so sehr? )
Ich python3.8 die Version von python3.8 , da diese über das addon nicht korrekt funktioniert hat und Travis CI erfolgreich virtualenv aus der angegebenen Version erstellt.
Personen, die mit Travis CI vertraut sind, werden sich fragen, warum sie nicht ausdrücklich Python-Versionen auf diese Weise angeben sollten. Schließlich erstellt Travis CI automatisch virtualenv und führt die erforderlichen Befehle darin aus.
Der Grund dafür ist, dass wir Codeabdeckungsdaten aus allen Versionen erfassen müssen. Die Tests werden jedoch in verschiedenen Jobs gleichzeitig ausgeführt, weshalb es nicht möglich ist, einen allgemeinen Abdeckungsbericht zu erstellen.
Natürlich bin ich mir sicher, dass etwas mehr Verständnis und dies behoben werden kann.
Traditionell wird README.rst auch ein Link zu einem Abzeichen hinzugefügt
|Build Status Travis CI| .. |Build Status Travis CI| image:: https://travis-ci.org/zifter/numeral-system-py.svg?branch=master :target: https://travis-ci.org/zifter/numeral-system-py
Die Dokumentation
Ich denke, jeder Python-Entwickler hat den Service mindestens einmal genutzt - readthedocs.org . Es scheint mir, dass dies der beste Service für das Hosting seiner Dokumentation ist.
Ich werde das Standardwerkzeug zum Generieren der Sphinx- Dokumentation verwenden. Ich folge den Schritten aus dem Starthandbuch und erhalte die folgende Struktur:
src/ docs/ build/ # html source/ # _static/ # , , _templates/ # conf.py # index.rst # make.bat Makefile # make make
Als Nächstes müssen Sie die Mindestschritte ausführen, um Folgendes zu konfigurieren:
github schlägt standardmäßig vor, eine README.md Datei im Markdown- Format zu erstellen, wenn es standardmäßig als sphinx Verwendung von ReStructuredText vorschlägt .
Daher musste ich es im .rst Format umschreiben. Und wenn ich das Starthandbuch mindestens einmal bis zum Ende durchgelesen hätte, hätte ich gemerkt, dass sphinx das in Markdown kann .
Ich index.rst README.rst Datei in index.rst
.. include:: ../../README.rst
- Um die Dokumentation automatisch aus den Kommentaren in der Quelle zu generieren, füge ich die Erweiterung sphinx.ext.autodoc hinzu .
- Ich
conf.py zu conf.py Dadurch kann sphinx unseren Code zur Analyse importieren.
import os import sys sys.path.insert(0, os.path.abspath('./../../src')) import numeral_system
- Ich füge den Ordner
docs/source/api-docs hinzu und lösche dort die Beschreibungsdatei für jedes Modul. Die Dokumentation sollte automatisch aus Kommentaren generiert werden:
Roman numeral system ========================= .. automodule:: numeral_system.roman :members:
Danach ist das Projekt bereit, der Welt seine Beschreibung zu offenbaren. Sie müssen ein Konto erstellen (vorzugsweise über ein Konto bei github ) und Ihr Projekt importieren. Die detaillierten Schritte sind in der Anleitung beschrieben .
Aus Tradition schaffe ich eine Umgebung in tox :
[testenv:gen_docs] deps = -r docs/requirements.txt commands = sphinx-build -b html docs/source/ docs/build/
Ich verwende den sphinx-build explizit anstelle von make , da er unter Windows nicht existiert. Und ich möchte nicht gegen das Prinzip der plattformübergreifenden Entwicklung verstoßen.
Sobald die Änderungen eingefroren sind, readthedocs.org automatisch die Dokumentation und veröffentlicht sie.
Aber ... Build failed . Ich habe die sphinx_rtd_theme sphinx und sphinx_rtd_theme nicht sphinx_rtd_theme , und ich habe erwartet, dass readthedocs.org die aktuellen Versionen übernimmt. Aber das ist nicht so. Ich repariere:
sphinx==2.3.1 sphinx_rtd_theme==0.4.3
Und ich erstelle eine spezielle Konfigurationsdatei .readthedocs.yml für readthedocs.org , in der ich die Umgebung zum Starten des readthedocs.org beschreibe:
python: version: 3.7 install: - requirements: docs/requirements.txt - requirements: requirements.txt
Hier hat sich als nützlich erwiesen, dass sich die Abhängigkeiten in den requirements.txt Dateien befinden. Ich warte auf den Build und die Dokumentation wird verfügbar .
Fügen Sie das Abzeichen erneut hinzu:
|Docs| .. |Docs| image:: https://readthedocs.org/projects/numeral-system-py/badge/?version=latest&style=flat :target: https://numeral-system-py.readthedocs.io/en/latest/
Lizenzierung
Es lohnt sich, eine Lizenz für das Paket zu wählen.
Dies ist ein sehr umfangreiches Thema, daher habe ich diesen Artikel gelesen. Grundsätzlich besteht die Wahl zwischen MIT und Apache 2.0 . Ich mochte die Phrase, die erfolgreich aus dem Kontext genommen wurde:
MIT
Ich stimme vollkommen zu, ich werde das tun. Wenn sich die Pläne ändern, können Sie die Lizenz leicht ändern (obwohl frühere Versionen unter der alten Version sein werden).
Fügen Sie erneut ein Abzeichen hinzu Abzeichen Gott :
|License| .. |License| image:: https://img.shields.io/badge/License-MIT-yellow.svg :target: https://opensource.org/licenses/MIT
Hier finden Sie Ausweise für alle Lizenzen.
Wie lade ich auf pypi hoch?
Zuerst musst du ein Konto auf pypi.org erstellen . Fahren Sie dann mit der Vorbereitung des Pakets fort.
Ich erstelle setup.cfg
Es ist erforderlich, die Konfiguration für die Installation / Erstellung des Pakets korrekt zu beschreiben. Ich habe die Anweisungen befolgt. Es ist möglich, Daten über setup.py , es gibt jedoch keine Optionen zum setup.py einiger Parameter. Verwenden Sie daher die Datei setup.cfg , in der Sie alle Nuancen angeben können. Es wurde eine kleine Vorlage zum Füllen dieser Datei gefunden. Aus diesem Grund verwende ich sowohl diese als auch diese Datei - es ist praktischer.
Diese Datei kann auch zum Konfigurieren von pylint , flake8 und anderen Einstellungen verwendet werden, was ich jedoch nicht getan habe.
Wie baue ich ein Paket zusammen?
Wieder schreibe ich eine Umgebung, die mir hilft, das notwendige Paket zusammenzustellen:
[testenv:build_wheel] skip_install = True deps = ; wheel docutils pygments commands = python -c 'import shutil; (shutil.rmtree(p, ignore_errors=True) for p in ["build", "dist"]);' python setup.py sdist bdist_wheel
Warum lösche ich Ordner mit Python? Ich möchte die Anforderungen für die plattformübergreifende Entwicklung erfüllen. Unter Windows und Unix gibt es keine bequeme Möglichkeit, dies zu tun.
Ich starte die Testumgebung:
tox -e build_wheel
Als Ergebnis erhalte ich im dist Ordner:
dist/ numeral-system_py-0.1.0.tar.gz numeral_system-py-0.1.0-py2.py3-none-any.whl
Ich fülle aus!
Nicht wirklich.
Zunächst sollten Sie überprüfen, ob das Paket ordnungsgemäß funktioniert. Ich werde es in das Testpaket-Repository hochladen. Sie müssen daher ein anderes Konto erstellen, das sich jedoch bereits auf test.pypi.org befindet .
Ich benutze dafür das Bindfadenpaket - ein Werkzeug zum Auffüllen von Artefakten in PyPi.
[testenv:test_upload] skip_install = True deps = twine ; commands = python -m twine upload --repository-url https://test.pypi.org/legacy/ dist/*
Ursprünglich hieß das Projekt numsys , aber als ich versuchte, es zu füllen, stieß ich auf die Tatsache, dass es bereits ein Paket mit demselben Namen gibt! Und was ist am ärgerlichsten - er weiß auch, wie man in römische Ziffern konvertiert :) Er war nicht sehr verärgert und wurde in numeral-system-py .
Jetzt müssen Sie das Paket aus der Testumgebung installieren. Die Validierung sollte auch automatisiert werden:
[testenv:test_venv] skip_install = True ; deps = ; commands = pip install -i https://test.pypi.org/simple/ numeral-system-py
Jetzt musst du nur noch laufen:
tox -e test_venv ... test_venv: commands_succeeded congratulations :)
Es scheint zu funktionieren :)
Jetzt auf jeden Fall gießen!
Ja
Ich erstelle eine Umgebung zum Hochladen in das Produktions-Repository.
[testenv:pypi_upload] skip_install = True deps = twine commands = python -m twine upload dist/*
Und die Umgebung für die Produktionsüberprüfung.
[testenv:pypi_venv] skip_install = True deps = ; commands = pip install numeral-system-py
Funktioniert alles
Ich überprüfe mit einfachen Befehlen:
> virtualenv venv > source venv/bin/activate (venv) > pip install numeral-system-py (venv) > python >>> import numeral_system >>> numeral_system.roman.encode(7) 'VII'
Alles in Ordnung ist!
Ich schneide das Release auf Github , sammle das Paket und fülle es in die Propi Pypi.
Bemerkungen
Abhängigkeitsaktualisierungen
Während der Vorbereitung dieses Artikels wurde eine neue Version von pytest veröffentlicht, in der tatsächlich die Unterstützung für Python 3.4 eingestellt wurde ( tatsächlich im colorama- Paket enthalten). Es gab zwei Möglichkeiten:
- Commit colorama version kompatibel mit 3.4;
- Drop Unterstützung 3.4 :)
Das letzte Argument für die zweite Option war, dass pip die Unterstützung 3.4 in Version 19.1 eingestellt hat.
Es gibt auch feste Abhängigkeiten in Form von Analysatoren, Formatierern und anderen Diensten. Diese Abhängigkeiten können gleichzeitig aktualisiert werden. Wenn Sie Glück haben, steigen Sie nur mit der Upgrade-Version aus, wenn nicht, müssen Sie den Code korrigieren oder sogar die Einstellungen hinzufügen.
TravisCI
Unterstützt kein Python für MacOS und Windows. Es gibt Schwierigkeiten bei der Ausführung von tox für alle Versionen von Python innerhalb eines Jobs.
Paketversion
Die semantische Versionierung muss eingehalten werden , und zwar das Format:
MAJOR.MINOR.PATCH
Die Version des Pakets und einige andere Parameter müssen angegeben werden, um das Paket (in setup.cfg oder setup.py ) und in der Dokumentation zu installieren. Um eine numeral_system/__init__.py zu vermeiden, gab er nur im Paket numeral_system/__init__.py :
__version__ = '0.2.0'
Und dann setup.py in setup.py explizit diese Variable
setup(version=numeral_system.__version__)
Gleiches gilt für docs/source/conf.py
release = numeral_system.__version__
Das Obige gilt für alle Metainformationen - REAMDE.rst , Projektbeschreibungen, Lizenzen, Autorennamen und mehr.
Dies führt zwar dazu, dass die Verpackung zum Zeitpunkt der Montage importiert wird, was möglicherweise unerwünscht ist.
Abhängigkeitsduplizierung
Am Anfang war ich verwirrt von der Tatsache, dass ich Abhängigkeiten für das Paket in requirements.txt und setup.cfg .
, — setup.cfg .
. , requirements-dev.txt .
, src/ . :
:
— .
, :
Add badge with supported version Support for py38
:
Try fix py38 env creating Try fix py38 env creating Try fix py38 env creating Fix check
, 3 ! Travis CI.
, . — , .
, . CHANGELOG .
, Markdown . , rst .
Abzeichen
— , , , . , .
coverage .
-
, , , . six , , type hint , asyncio — .
python2.7 , . , python3.5+, . , , CI . .
?
, :
Fazit
open source , .
, python github , .
stackoverflow.com issues github .
. . ?..
, , .
, .
github .
Vielen Dank!