Bitte um Feedback: Tutorial über Python Packaging

[buhtz]

X-Post (ohne Response) auf python-list@python.org, r/pythoncoding und setuptools/Discussions.

Hallo,

ich möchte gerne auf mein Tutorial aufmerksam machen und bin für Feedback sehr dankbar. Es gut um Packetierung von Python Anwendungen; jedoch nicht im Kontext Debian, sondern pures Python. Neben dem Tutorial Text sind auch mehrere Beispiel-Anwendungen im Repository enthalten.

https://codeberg.org/buhtz/tech-demo-python-packaging

Ich bin kein Experte auf dem Gebiet und vermute daher, dass einige meiner Lösungen nicht die besten oder unkonventionell sind. Daher wäre ich um Feedback von Experten oder anderen Erfahrenen sehr dankbar.

Zum Hintergrund: Als Teil des Upstream-Betreuer-Teams von backintintime bereite ich die Migration von einem make-basierten Build-System auf ein pures und modernes Python Build-System (pyproject.toml, etc) vor. Um einige erwartbare Probleme zu erforschen und Lösungen zu finden, habe ich diese im Tutorial enthaltenen Mini-Projekte entworfen.

Wenn das Tutorial ein paar Reviews übersteht, würde ich im nächsten Schritt dazu übergehen, etwas ähnliches auch für Python Debian Packaging zu machen.

Herzlichen Dank für die Aufmerksamkeit
Christian

[TRex]

Hi,

ich bin jetzt bis zur Internationalisierung gekommen - bis dahin gefällt es mir ganz gut. Den Weg zum src-Layout hab ich auch erst dieses Jahr gefunden; man könnte im Absatz noch hervorheben, dass hinter dem Link ne Diskussion dazu steckt. Ich hab aber nicht verstanden, warum da ein test_dummy.py auf toplevel liegt (ist nur ein Fehler in der Doku, im fs liegts unter tests).

Zu i18n: dass setuptools da wieder gegen ein neueres Tooling abstinkt, ist nichts neues, aber schade.

Gibts nen Grund, warum du dich für hatchling entschieden hast? Bei meinem Brötchengeber ist poetry all the rage (nicht unbedingt mein Favorit, ich mags vanilla und darum auch meine Enttäuschung über den Ausgang bei i18n).

Was mir nebenbei aufgefallen ist: die dritte Form Singular von "(to) do" ist "does" - das hab ich oft falsch geschrieben gelesen.

[buhtz]

Hallo TRex,
vielen Dank für deine Rückmeldung.

Das "test_dummy.py" auf dem flaschen Level ist, liegt daran, dass ich in meinem Emacs die Tabs immer noch nicht ganz unter meiner Kontrolle habe.

Gibts nen Grund, warum du dich für hatchling entschieden hast? Bei meinem Brötchengeber ist poetry all the rage (nicht unbedingt mein Favorit, ich mags vanilla und darum auch meine Enttäuschung über den Ausgang bei i18n).

Ich bin kein Experte und habe auch keinen Überblick oder besondere Erfahrung mit anderen build-systemen. Für ein Einsteiger-Tutorial sollte es eben auch vanilla sein. Laut meiner Recherche ist hatchling sehr simpel gehalten und PEP-konform. Es war mein erster Versuch mit hatch.

Poetry ist to much. Und es hält sich bewusst nicht an die PEPs. Sowas wie poetry und tox, ist für Einsteiger zu viel. Ja, hatchling kann sowas ähnliches auch tun, habe ich gelernt. Mein Problem in der Python-Welt ist, dass häufig Tools empfohlen werden, bloß weil sie für sich selbst gesehen gut bis genial sind, ohne dass man dabei auf den Anwendungsfall und die Notwendigkeiten achtet. Häufig ist es so ein Kanonen-auf-Spatzen-Ding und gerade als Anfängern holt man sich mit Poetry/Tox & Co viele weitere Probleme mit ins Boot. Das kann man nutzen, wenn man wirklich weiß, wofür man es benötigt. Vorher nicht. Vorher nur "vanilla". Führerschein macht man i.d.R. ja auch nicht in einem Ferrari oder Maibach.

Ehrlich gesagt, kenne ich bisher auch keinen Anwendungsfall für poetry/tox. Multi-Python-Version-Build-Matrizen haben IMHO in einem Uptream repo nichts zu suchen. Bin schon froh, wenn Contributoren überhaupt unit-tests laufen lassen. Dann muss man sie nicht auch noch mit tests verschiedener Python Binaries und deren Installation belästigen. Aber das ist ein anderes Thema und meine Ansichten sind diesbezüglich auch etwas unkonventionell.

Die ständige Empfehlung für Sphinx ist IMHO auch ein weiteres Beispiel für Tool-Empfehlungen am Anwendungsfall vorbei.

Was mir nebenbei aufgefallen ist: die dritte Form Singular von "(to) do" ist "does" - das hab ich oft falsch geschrieben gelesen.

Oh ja, das English ist nicht schön; mein Deutsch auch nicht. Steht auf meiner ToDo Liste.