Transcript: Python Packaging

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der 34. Episode heute.

Ja, wir nehmen wieder abends auf, Ausnahmsweise, muss ja auch mal sein.

Schön, dass ihr wieder eingeschaltet habt. Was machen wir heute? Wir wollten ein bisschen was über Pakete besprechen.

Der Jochen ist natürlich wieder dabei und wir haben wieder einen Gast. Hi Jochen.

Und der Gast ist heute wieder der Ronny. Hi Ronny.

Hi.

Hallo.

Ich bin der Dominik.

Ja.

Ja.

Ja.

Ja.

Ja, ich weiß nicht, ob wir wieder Struktur machen wollten, ein bisschen News oder so.

Habt ihr News?

Nee, ich bin zu irgendwie nicht viel gekommen

und habe auch keine Newsletter oder sonst irgendwas gelesen.

Ja, okay.

Also es kam tatsächlich der Copilot

auf GitHub heute raus zum Coden.

Das fand ich ja ganz interessant.

Das ist jetzt keine Python-News, aber...

Ja, man kann sich da anmelden, irgendwie eintragen

in so einer Testerliste.

Es gibt auch ein VS Code Plugin für die Leute, die das nutzen.

Was macht das denn?

Das ist ein Copilot für GitHub,

der, wenn man Docstring schreibt,

automatisch die Funktion baut, der für

verschiedene Sprachen funktioniert. Sieht

ziemlich nice aus. Also so die Demo,

wenn das mal richtig gut funktioniert, irgendwie mit

Machine Learning dahinter wahrscheinlich so ein bisschen,

bleibt einfach ein coolen Docs-Ding und der

baut die ganze Funktion so zusammen, wie er es für richtig hält.

Ja, ich habe das irgendwie, ich habe nur so

ein Animated

GIF auf Twitter oder so gesehen,

wo da jemand bezeichnet Learn, was er gemacht hat und das

sah schon gut aus, aber

ehrlich gesagt, ich würde mir jetzt nicht trauen, dass ich

sage, okay, das tut jetzt genau das, was ich gerne hätte.

Das heißt, man muss den Code dann zumindest nochmal

lesen. Ja, ich glaube, lesen muss man es natürlich schon.

Aber es ist ja relativ super, um wahrscheinlich bekannte

Patterns so zu verstehen. Und auch für

Sprachen, die man vielleicht noch nicht so gut kann, dass man halt so

grundsätzliche Konzepte da sehr schnell mitlernen

kann. Das muss auch super interessant sein.

Außerdem wird man gezwungen, Dokumentationen zu schreiben.

Am Anfang, das ist vielleicht auch gar nicht

so doof. Also es ist halt die Frage,

wohin das hinschaut, wenn das halt nur KI-gesteuert ist,

irgendwann, je nachdem, wie gut die Qualität

heute ist, hier und da zu schreiben, was dann dabei rauskommt.

Ja, das ist

die durchschnittliche GitHub-Code-Qualität.

Ich meine, wenn das jetzt, also

kann ja eine Verbesserung sein.

Ja, genau. Also ich finde es wirklich interessant

und es sah auch echt top aus.

Documentation-Driven-Development.

Irgendwie so, ja.

Specification-Driven-Development.

Ja, also diese Beispiele auf der Seite vom

Co-Piloten da, die sahen echt schick aus, auch in

Python, die es da gab.

Okay, ja, cool. Das ist auf jeden Fall eine Neuigkeit, ja.

Ja, haben wir noch was?

Ich glaube, was hast du gesagt? Python 306?

Ja, egal. Ja, ist heute vor drei

Tagen oder so rausgekommen.

aber ich weiß ehrlich gesagt nicht mehr, was der Unterschied ist, weil mich die Wachsend gerickt

waren. Voll gut, nur so eine Erinnerung, dass man das jetzt mal dann installieren könnte.

Aber ansonsten. Nicht, was passiert. Dann würden wir doch direkt

darauf vorgekommen. Oder fällt dir noch was ein, Ronny? Ist doch eigentlich eine gute Überleitung, so GitHub

Packages. Stimmt. Packages, was ist denn das? Ein Package?

Genau, das ist das Thema. Packaging.

Was ist das? Wie macht man das denn? Wie spricht man das aus? Ganz wichtig.

ein Paket. Also ihr wollt irgendwas machen wie ein Paket schreiben, ein Modul schreiben.

Was ist ein Modul? Und das Veröffentlichen, vielleicht ist Veröffentlichen

eine der Sachen, die man damit machen will mit einem Paket? Oder Wiederbenutzen vielleicht?

Ja, selbst wenn man das nur irgendwie, wenn man einen Code miteinander teilen

will, ist es wahrscheinlich schon eine ganz gute Idee unter Umständen das halt als Paket

zu tun und nicht direkt als Repository.

Das heißt, da können bestimmte Dinge dazu, sowas wie eine Bauanleitung oder sowas?

Ja, also

es gibt unterschiedliche Arten von

Paketen. Das ist vielleicht schon mal so

ein grundsätzliches Ding, mit dem man anfangen kann.

Also es gibt halt zum Beispiel, also oder

weiß nicht, wo wir damit anfangen, oder mit der Geschichte

von Packaging.

Ja, okay, ich bin gespannt. Ich hätte gedacht, es gibt noch

DCPIP, aber tschuldigung.

Da gibt es auch Pakete.

Vielleicht nur so ganz kurz, es ist halt leider verwirrend,

es ist kompliziert und es ist komisch und es ist

alles nicht so einfach in Python leider.

Das hat glaube ich angefangen alles

1998 mit Bistutils

und

das ist auch in der Standardbibliothek, ist da immer noch

drin. Also es geht eigentlich darum, wie gibt ihr

denn euer Programm irgendwem,

der es dann ausführen möchte?

Ja, wie kann man

Code so verpacken,

dass man das irgendwo anders dann halt einfach nur

das Paket installiert und nicht den kompletten

Repository.

Oder der weiß

gar nicht, was für einen Computer der hat oder

verschiedene Herausforderungen.

Genau, und dann irgendwann kamen halt Setup-Tools

dazu, damit

hat man dann zum ersten Mal...

Wenn wir jetzt schon mal wieder bei Python-Podcast noch ein bisschen

einsteigen, was ist denn Distutils?

Genau, das ist halt so ein Ding, um

zum Beispiel,

ja, wenn man jetzt in einem

Verzeichnis ist, wo man den Code hat, daraus irgendwas zu

bauen, was man dann als Paket weitergeben kann.

Und da

kommen auch an so ein paar von den Begriffen, meine ich

jedenfalls her, sowas wie S-Dist zum Beispiel

oder BDist, aber ich weiß nicht,

ob es da schon wirklich dabei war.

Also S-Dist ist halt Source-Distribution

und

sagt eigentlich im Grunde, dass man halt nur

den Code irgendwie ins Paket packt,

also den Source ins Paket packt und dann halt

auf dem Zielsystem halt eventuell noch,

wenn da Extensions, zum Beispiel C-Extensions

oder so drin sind, muss man die dann halt

noch bauen. Also es ist halt noch nicht gebaut,

es sind nicht die pyc-Files, sondern

es sind nur tatsächlich die

.py-Files

und weil

die PYC-Files, das hängt auch von

Interpreter-Versionen ab und so.

Und dann gibt es halt die

BDIS, also die Build Distribution

Pakete.

Und das sind halt irgendwie TAR-Balls

vor allen Dingen gewesen oder manchmal auf Windows

glaube ich auch ZIP-Files, weiß nicht genau.

Aber es ist noch kein richtiges Paketformat.

Und dann kamen irgendwann Setup-Tools dazu

und weiß nicht, irgendwann

Anfang der Nullerjahre, keine Ahnung wann genau.

Und da war das Ziel

halt dann so ein Paketformat zu haben.

Das hatte man dann mit X auch.

aber das war es, was auch mehr oder weniger ein Zipfel war

und inzwischen sind es Wheels

das ist auch mehr oder weniger ein Zipfel

aber

so ein bisschen

sind die Dinge schon anders, also Wheels sind jetzt

deutlich schneller, kann man deutlich schneller auspacken

und verwenden als

X, X werden eigentlich nicht mehr verwendet

dann gab es irgendwie eine Zeit, in der ganz viel rumgeforkt

worden ist und dann sind Dinge

auch wieder zurück nach Setup Tools gegangen

und Setup Tools ist aber nie Teil der

Standardbibliothek geworden

Distutils war es dann aber auch schon immer schon lange

so dass heute ist es halt so

es gibt halt Dinge, die macht Distutils

wenn man ein Paket baut

es gibt Dinge, da benutzt man Setup-Tools für

was ein bisschen komisch ist, weil man

das ist halt nicht in der Standardbibliothek, man muss dafür Setup-Tools installieren

und Setup-Tools hat dann wiederum Plugins

für bestimmte Sachen, wie zum Beispiel wenn man Wheels bauen will

dann gibt es halt das Wheels-Paket

das man dann noch installieren kann und das bringt dann halt

ein Plugin für Setup-Tools mit

womit man dann halt auch Wheels bauen kann

Ja, okay

Das klingt aber so, als geht das halt nicht

out of the box und da brauchen wir schon noch andere Sachen

Ohne C-Compiler geht das wahrscheinlich dann nicht

Doch, also wenn man

zum Beispiel einfach nur

reine Python, also wenn der

Code, den man geschrieben hat, einfach nur

Python-Code ist, dann

braucht man eigentlich sonst nichts zu machen

dann ist auch eine Source-Distribution

im Grunde schon

ausreichend

aber wenn man jetzt halt C-Extensions dabei hat oder sonst

und Jochen unterhalten sich über die Programmiersprache Python

auf einer Maschine mit M1 oder so,

damit ich das mal da bauen kann, weil ansonsten kann man

halt keine Wheels bauen. Das geht halt nicht. Das kannst du nicht auf einer

Intel-Maschine

machen.

Und das ist alles so ein bisschen hässlich.

Und, ah ja, Gott.

Ja.

Es ist kompliziert, leider.

Okay, dann habe ich Wheels gebaut und die kann ich

dann irgendwie auf PyPI stellen und

das wäre heute der Weg. Aber nicht nur die

Wheels, sondern auch Source-Distribution

und Build-Distribution kann man auch auf

PyPI stellen.

und passiert auch oft. Und oft muss man es dann auch selber

kompilieren noch, wenn es halt keine Wheels gibt.

Zum Beispiel, was mir eben,

ich habe jetzt auch hier so ein M1 weg und das

passiert regelmäßig, dass ich irgendwie Pandas oder

NumPy und dann ein Großteil des Zeugs unten

drunter muss halt dann noch kompiliert werden

und das dauert halt relativ lang. Zum Beispiel, wenn

jetzt dann sowas wie Python 3.9.6

irgendwie rausgekommen ist,

dann gibt es halt für Pandas und NumPy noch keine

Wheels und dann wird dann halt schön selber

kompiliert, was dann halt mal ein paar Minuten

dauern kann.

und

einem zur Verzweiflung treibt,

wenn irgendwelche Details in dieser Compile-Pipeline

und irgendwann, wenn der Vortragskompiler nicht richtig

ist oder keine Ahnung, irgendwas

bei der Emulation von

bei der, bei der, das Intel-Prozessor

nicht richtig funktioniert oder so und dann hat man

sehr, sehr komische Fehlermeldungen aus den Tiefen

von irgendwelchen Compiler-Toolchains.

Ja, also tatsächlich auf

anderen Systemen bauen zu

wollen ist dann, oder an neuen Versionen

ist dann vielleicht immer nicht ganz so einfach.

haben. Aber das Gute ist, dass

man ja tatsächlich auch, wenn man jetzt, vor allem wenn man

jetzt mal anfängt, dass man ja dann doch eher in der

reinen Python-Welt bleibt und dass man dann das auch

relativ entspannt einfach

ohne irgendwelche großen Probleme

die Packages erstens bauen kann

und zweitens dann auch die dann auch wieder leicht

installieren kann.

Also man kann sich relativ

viel von diesem Complexities-Overhead sparen, indem man

quasi keine externen Libraries

verwendet oder sowas.

Genau, ja. Also reines

Python ist eigentlich relativ

einfach dann. Also das Einzige, was

halt dann mit in den

Build Distributions drin ist,

sind halt die PyC-Files.

Die was? PyC.

Ansonsten musst du die halt noch einmal von

Py nach PyC verwandeln, aber das ist auch alles...

Das merkt man heutzutage

gar nicht mehr.

Und dann hat man

so ein Paket und dann hat man das auf PyPI und dann kann

jeder das

laden. Ja. Über

PIP oder sowas. Genau.

Ja.

Ja, und die ganze Dokumentation

dazu, ich habe

mich ehrlich gesagt nicht wirklich

vorbereitet, aber ich habe einmal

geguckt,

was gibt es denn,

habe ich irgendwelche Bücher

zufällig, wo was drinsteht über Packaging

und da gab es irgendwie ein Buch

Python Expert Programming, da war ein bisschen was drin,

ein Kapitel und

ansonsten

ja, hier klingeln

Dinge. Das ist immer sowas,

Telefon auf Flugmodus stellen.

Ja, ja.

Wir müssen das alte QP mit dem Hintergrund,

du kennst das noch.

Oh ja, das ist lange her.

Was sind hier der Flugmodus?

Da ist er doch.

So.

Ja.

Genau.

Also die

autoritative Quelle für Dokumentation über

dieses ganze Packaging-Thema

ist

packaging.python.org

also die Python Packaging

Authority, PyPA nennt die sich auch.

Und da kann man

das alles, also die ganzen Details, die ganzen fiesen

Details, die stehen da alle drin. Und

was mich sehr gefreut hat, das ist

genauso aufgebaut wie

es gab da ja, das hatten wir das letzte Mal

auch schon von

documentation.divio.com

Ja.

Also es gibt auch einen schönen

Vortrag eben

von Daniele

Proshida über

wie schreibt man eigentlich

Dokumentationen sinnvollerweise und der teilt das halt

auf in, naja, es gibt halt

unterschiedliche Quadranten und

unterschiedliche Zielrichtungen und

dann schreibt man halt Tutorials, How-to-Guides,

Explanations oder Reference-Documentation

und das kann man alles mit

Pleasure.

Er hat mit dem Vortrag Programming for Pleasure gemacht.

Genau, das war dieses Jahr, das war glaube ich hier

wo er über Dokumentationen Vortrag gemacht hat,

war 2017 oder so.

Kann man sich auch angucken, haben wir letztes Mal schon verlinkt in der

JagoCon Europe Episode, sehr empfehlenswert.

Und was ich halt gesehen habe, ist, dass Pipey

hält sich genau da dran. Da sieht man halt, genau, sie machen Tutorials,

dann machen sie How-To-Guides und dann machen sie irgendwie Discussions

und dann gibt es dann halt irgendwie auch noch eine Referenz-Dokumentation.

Also sie haben das genau so aufgeteilt und sich daran orientiert,

das fand ich irgendwie...

Dokumentation ist auch sowas, was ich irgendwie zu wenig tue.

Ja, du sagst ja auch immer, guter Coach spricht für sich selbst.

Genau, braucht man das alles gar nicht.

So ein Quatsch, Dokumentation.

Ich versuche tatsächlich

alle Sachen, die ich wahrscheinlich wieder vergesse,

so aufzuschreiben, dass

da auch jemand anders, der das vielleicht liest,

dann auch noch machen könnte.

Man ist selber in einem halben Jahr und freut sich.

Ja, genau.

Das ist immer ganz nett.

Man ist auch schneller beim zweiten Mal, wenn man halt einfach seine eigene Doku lesen kann

und sich nicht immer komplett von neuem irgendwo

einarbeiten muss.

Ich finde tatsächlich, dass man auch mit inneren Dokumentationen sehr viel gewinnen kann.

Ja.

ein bisschen faul.

Aber das ist eigentlich gar nicht das Thema.

Ja, aber

ich meine immer

ja, also wobei, ich weiß nicht,

bei Dokumentationen innerhalb von

Source Code oder Kommentare

in Source Code finde ich immer ein bisschen schwierig.

Also es kommt darauf an, was es ist. Manchmal auch natürlich

stellen, wo das total sinnvoll ist, aber manchmal ist es halt auch echt,

weil das tendiert auch dazu, dann irgendwie so

auseinanderzulaufen. Also warum man so

bestimmte Sachen macht, die irgendwie komisch aussehen, dass das vielleicht

manchmal gar nicht so schlecht ist.

Nee, genau, genau. Durchaus sinnvoll.

aber

ja, von

wie heißt der noch?

Dingsdar

Dingsdar

CleanCode

Uncle Bob

der sagt ja immer, das erste was er macht, wenn du durch Code gehst, ist halt

die ganzen Kommentare entscheiden

weil sie verwirren nur

weil, ja

aber es kommt halt

drauf an, also ich meine, es gibt halt so die Fälle

wo es klar ist, dass es verwirrend ist, aber es gibt

halt auch die Fälle, wo es total sinnvoll ist

Ich finde, das kann sehr viel Vertrauen schaffen.

Also wenn ich ein Package mir angucke

und ich überlege,

ob ich das nutzen möchte und vielleicht auch produktiv nutzen möchte

und da ist halt gar nichts dokumentiert,

dann habe ich direkt schon mal so ein großes Fragezeichen im Kopf,

ob ich das wirklich nutzen möchte.

Wenn das gut strukturiert ist, gut dokumentiert ist,

dass das lesbarer Code ist,

vernünftig aufgeräumt ist, das macht schon echt viel aus.

Ja.

Ein bisschen moderner Stil. Wir haben ja alle so einen gewissen Taste

mittlerweile.

Ja.

Ja, aber wir

Wir sind gerade bei Dokumentation gelandet,

aber wir sind ja über Packaging

dahin gekommen.

Wir haben jetzt gesagt,

Setup-Tools des Utils,

PIP,

es gibt noch irgendwie dann so bestimmte Sachen,

die man dann braucht, was wie eine Setup-Pi,

oder ich habe gesehen, man kann sowas auch mit Poetry und dann Pi-Project-Hummel

jetzt so ein bisschen basic

einrichten.

Das ist doch mal...

Ja, also wie man jetzt

zum Beispiel die Metadaten zu einem

Paket.

Ah, Moment, man braucht Metadatentime-Paket natürlich.

Ja, ja, also zum Beispiel so was simples wie

wie soll das Paket heißen?

Das muss man ja irgendwo hinschreiben.

Und da gibt es halt mehrere Methoden.

Ja, das, was man,

ich glaube, das ist auch das älteste Setup-Py.

Also da ruft man halt Setup auf und

irgendwie die ganzen Parameter sind im Grunde alles

mehr oder weniger Argumente

dieser Funktion.

Das ist sehr dynamisch und so.

Da kann man natürlich tolle Sachen machen, da kann man dann

so Sachen reinschreiben, wie man holt sich

die Version von dem Paket

aus irgendeiner Init-Py in dem Paket

selber oder solche Sachen.

Aber auf der anderen Seite

macht das halt

der Infrastruktur drunter

das sehr, sehr schwer, dass das so dynamisch ist.

Und...

Bei Project Home ist das ja auch ähnlich.

Es geht ja mit Poetry, wenn man damit arbeitet, auch so

Bildbefehle. Und da kann man ja auch die

Version direkt reinschreiben und einen kleinen Doxing reinschreiben

und den Namen reinschreiben und so ein bisschen

sich überlegen, was denn da

stehen soll in dem Paket.

Ja, ich weiß jetzt gar nicht so ganz genau, wie das bei Poetry

dann tatsächlich darunter funktioniert. Also ich habe es schon benutzt,

aber tatsächlich ist das für mich so ein bisschen

eine Blackbox irgendwie. Poetry

tut dann irgendwas und dann fällt ein Paket

raus. Also der

Standardweg, wie man das mit

Setup-Tools

macht, ist dann setup.cfg

wo man dann halt so

statische Metadaten drin hat

und keine Setup.py mehr verwendet.

Das ist auch das, was empfohlen wird. Also die ganzen Leute,

die sich da um dieses Python-Packaging-Ding

kümmern, die sagen alle, oh mein Gott, bitte, bitte,

bitte verwendet Setup.cfg,

das macht uns das Leben so viel einfacher.

Setup.py ist für uns ein Riesenproblem

eigentlich. Also ich glaube, Setup.cfg

ist viel davon, ist auch in PyProject.toml

da gewandert. Genau, also

PyProject.toml ist mehr oder weniger ein neues Format

dafür, ja. Und das ist halt die aktuellste

Art, wie man die Metadaten

sozusagen erfasst. Und das ist halt auch

Standard, ich glaube das ist

PEP

518 oder sowas,

glaube ich.

Ja, also das wandert jetzt alles in

PyProjectHummel rein und dann kann man das mit

Poetry, wertet das dann halt irgendwie aus und baut das dann.

Ob Poetry dann nochmal Setup-Tools

unten drunter verwendet, weiß ich jetzt ehrlich gesagt gar nicht.

Aber es gibt dann auch mehr Tools.

Also Poetry

gibt es, es gibt aber auch, ich glaube das ist

habe ich in letzter Zeit

viel Gutes drüber gehört, ist Flit.

Oh, Flit?

und es liest halt auch PyProjectHummel aus

und baut halt Pakete

und vor allen Dingen benutzt es halt

nicht, glaube ich, nicht SetupTools,

sondern macht das alles selber und es benutzt auch

nicht Vine, um dann hinterher die Pakete

hochzuladen, sondern macht das auch selber.

Das ist halt so eine komplett integrierte Geschichte.

Was heißt Flit? Das Symbol ist ein

Kolibri. Ich frage mich, ob das auch Flit tut.

Ich weiß jetzt nicht, wo der Name

herkommt. Keine Ahnung.

Also ein einfaches Modul, um Packages auf PyPy

zu bekommen.

Kenne ich auch nicht.

Klingt spannend.

Ich habe es jetzt letztens davon gehört,

also ich hatte schon mal vorher davon gehört,

aber jetzt nochmal ausführlicher

in einer Podcast-Episode

Talk Python to Me, wo

nicht Talk Python to Me, haha, falsch,

Test & Code, glaube ich,

Brian Ocken, der hatte

da Brad Cannon

zu Gast und

der halt

auch für diese PyPA

irgendwie wesentlich zuständig

ist und

ja, der sagte also, er benutzt auch selber

Flit und das würde ihm sehr gut gefallen,

weil es halt einfach schnell

und so und macht das, was es soll.

Während Poetry,

ich verwende ja Poetry normalerweise,

aber ehrlich gesagt so manchmal, ich hatte das jetzt auch

ich glaube in dem Stream,

wo ich da so Live-Sachen

gerade irgendwie entwickle,

da habe ich

ich habe dann irgendwann mal das

Virtual-End-Fact schmeißen müssen und dann

habe ich nochmal als irgendwie

neu von PyPI gezogen

und Pootree

Update gesagt oder Install, ich weiß es gar nicht mehr genau.

Und dann hat das tatsächlich geschlagene

300 Sekunden

Dependencies aufgelöst.

Wo ich dachte so...

Das passiert, seitdem es das Async macht.

Ja, mir geht das an einen zu erscheinen auf die Nerven.

Da ist irgendwas richtig kaputt, weil

das darf nicht...

Ich kann mir nicht vorstellen, wie das irgendwie...

Welchen Grund es dafür

geben könnte.

Ich meine, so viele Pakete sind es nicht.

Vielleicht 50 oder so, die da drin sind, Abhängigkeiten.

Und dass das dann irgendwie,

also selbst ein paar Sekunden wäre viel zu viel,

die Abhängigkeiten da aufzulösen.

Wie kann das sein, dass das 300 Sekunden braucht?

Irgendwas ist da...

Oder es braucht es halt irgendwie, wenn es ein Netzwerk macht,

das kann natürlich auch sein,

und PyPI überlastet ist oder so,

vielleicht würde PIP auch so lange brauchen.

Aber Poetry bringt ja einen eigenen Resolver mit

und macht das halt nicht über PIP.

Aber offenbar ist das irgendwie nicht so ganz okay.

also Poetry hat mir schon so ein paar Mal

irgendwie tatsächlich echt

ich dachte so, okay, da ist irgendwas

nicht in Ordnung, insofern

Also falls ihr schon immer mal Open Source entwickeln

wolltet, scheint es, es gibt da ein paar

Pulverquests, die notwendig sind.

Keine Ahnung, vielleicht muss ich mal reingucken, was da los ist,

aber irgendwas, also das, da

kriege ich auf jeden Fall, wenn ich sowas sehe, kriege ich einen Schreck,

weil das finde ich ja so, oh, das ist ein Tool, auf das ich mich

verlasse und das macht komische Dinge

und

das hat auch so, was mich auch bei

Poetry so ein bisschen

wo ich auch dachte, ach das ist nicht so schlimm

aber das hat dann doch

macht auch immer wieder Probleme

ist halt, dass man

das gibt es bei den Setup-Tools

man kann Python Setup

py-develop ausführen

oder halt pip-i

und damit halt so eine editierbare

Version von einem Paket installieren

das halt, wenn man es entwickelt, super praktisch ist

und das geht mit Poetry

geht das nicht. Also geht einfach

gar nicht. Und was meinst du mit

editierbare Version installieren? Also da lädt quasi

seine lokale Datei

als Symblink

in... Ja, ja, ja, genau.

Es ist nur tatsächlich im

Virtual Env landet dann halt nur so eine Art Link

und sobald man den Code ändert, dann

muss man halt nicht irgendwie nochmal

neu das Paket installieren, sondern das ist halt

dann die geänderte Version vom Code

ist dann halt direkt da. Das ist tatsächlich

ein ganz, ganz wichtiger Punkt, den ich auch lernen

musste, wenn man mit einem Package arbeitet,

und Jochen unterhalten sich über die Programmiersprache Python

Ich habe gehört, Portree sei besser, keine Ahnung.

Ne, weiß ich nicht.

Naja, auf jeden Fall, ich bügele

das dann halt einfach nochmal, also alles mit

Pip installiert und so und dann einfach manuell nochmal

mit Pip dann das drüber bügeln, um diesen

Sim-Link zu machen und damit kann man dann sehr, sehr

entspannt und sehr cool, dann auch mit zwei

verschiedenen IDEs einfach, im einen

ändert man halt dann den

Package, was man gerade, oder den Source-Code des Packages,

im anderen hast du quasi deinen richtigen

Django-Web-Server oder was auch immer

dein Projekt macht und

das ist sehr, sehr convenient und da muss man

erst mal wissen, was man suchen muss.

Also du hast auch schon mal so ein paar

Pakete gebaut. Ich glaube, das hast du auch

bei GitHub hochgestellt.

Genau, ja. Ich habe vor ein paar

Jahren die

Ownership von dem Package übernommen

oder Maintainership von dem Package übernommen.

Das habe ich auch schon mehrfach

am Rande mal erwähnt auf ein paar Blog-Einträgen

und sowas. Das ist dieses wunderbare AI

Django Core Package.

Das ist entstanden

aus. Wir hatten

in der Frühzeit unsere Geschichte, also bei

AI hat nichts mit künstlicher

Intelligenz zu tun, etwas misleading.

Haben wir gemerkt, dass wir halt irgendwie

ganz praktische Sachen gebaut haben und dass man die halt

irgendwie immer vom Projekt zu Projekt kopieren ist doof.

Und da so, ja, machen wir mal ein Package

und dann ist es halt einfacher zu installieren.

Und hat man auch ein bisschen, wenn man mal einen Bug gefixt hat,

dann ist dann halt die Jahre.

Also für die verschiedenen Projekte, das heißt, du kannst in jedem

Projekt einfach sagen, okay, den Kone nehme ich jetzt immer mit und habe

die Basisfunktionalität. Genau, ohne dass man es halt kopieren

muss und hat halt dann keine Code-Renundanzen und so was.

Und wie gesagt, wenn man einen Bug fixen möchte oder irgendwas

Ja, vor allem, das ist halt blöd, wenn man halt irgendwas weiterentwickelt,

ein neues Feature, und dann muss das in jedem einzelnen Projekt

wieder nachbauen, das ist natürlich nicht so gut. Genau, das ist sehr mühsam.

Genau, und dann haben

wir uns dann, dann ist da halt

über Jahre dann so

Einbahnstraßen-mäßig da halt Code hineingeflossen.

Auch dann irgendwie gab's

dann irgendwann mal diesen großen Break, wo dann wirklich

alle von Python 2 weg sind.

Und dann waren da noch Python 2 Sachen drin, Python 3 Sachen

und dann irgendwann

habe ich mir das mal zur Brust genommen ich glaube das war so 2018 ungef habe ich mal angefangen zu gucken was ist da eigentlich drin weil ich da selber auch ziemlich viel kontrib habe weil ich halt oft Sachen gebaut habe wo ich dachte ach das ist cool das w ich im n Projekt auch gerne nutzen

Oder das, keine Ahnung, zum Beispiel Richtung Test-Setup oder so Sachen, die einfach das Ganze ein bisschen streamlinen und ein bisschen mehr so machen, wie ich das für richtig halte.

Dann habe ich irgendwann mal angefangen zu gucken, was ist denn da eigentlich alles drin und wie gesagt, da waren Kompatibilitätsprobleme und da war anfangs noch kein Linting drin und die Dokumentation, es war nichts dokumentiert.

und Jochen unterhalten sich über die Programmiersprache Python

und das habe ich die letzten Jahre halt dann angefangen und habe dann da in verschiedenen Wellen und Steps

ja, was gemacht. Also zum Beispiel super wichtig für mich

oder ein super wichtiges Learning für mich war, dass man ein Change Log macht, allein schon für einen selbst.

Ich habe keine Ahnung, was ich vor, also ich mache ungefähr

alle ein bis zwei Monate einen Release, also irgendeine Art von Release.

Kann mal ein Mad Release sein, wenn ich irgendwas Größeres wirklich rudimentär gemacht habe oder halt

was Kleineres, aber so ein bis zwei Monate. Das heißt, da kommen einige Releases

zusammen über die Zeit. Und wenn man

dann mal irgendein größeres

Projekt hat und das hochziehen möchte und denkt,

ich brauche jetzt dieses neue Feature, das da drin ist

und man nicht weiß, was man seitdem denn alles geändert

hat und nicht weiß, wie man sein

Projekt, dass man das aktualisieren möchte,

wie man das möglicherweise kaputt macht, das ist echt blöd.

Aber das geht ja dann auch direkt Richtung

wie vergibt man Versionsnummern

und was ist da?

Semantik-Versioning, glaube ich, habe ich gehört,

ist da en vogue.

Macht man das noch?

Ja, naja,

nicht, also ich weiß halt...

Wie immer lustig ist.

Ich guck mal...

Ich hab grad

einen Artikel,

der Semantic

Versioning won't save you.

Ja, also es kann ja zum Beispiel sein, dass man eine neue

Major Version rausbringt, so von 2 auf 3

oder sowas, dann gehen Dinge kaputt.

Das sind wir ja vielleicht nicht.

Ja, also genau, da gibt es einen sehr schönen Blogartikel

von

Hüneck, Heineck,

Schlawack, Semantic Versioning

will not save you, der ist auch jetzt, genau, der ist von Anfang März, den habe ich mich nicht erinnert.

Ja, leider ist das auch alles, also ich meine, es ist vielleicht besser als nichts, aber es ist halt,

es ist alles irgendwie...

Vielleicht, was ist das denn? Was ist denn Semantikwürfling? Was macht man denn da?

Naja, dass man sozusagen so ein bisschen, also nicht nur das hochzählt, sonst könnte man ja einfach

nur noch eine Zahl hochzählen, sondern dass da halt eine Bedeutung dran hängt, dass man zum Beispiel

so eine Dreiteilung hat.

Macht man bei

Setup-Tools auch oft so, dass man da

irgendwie dann Tuples verwendet, damit das klar ist, welche

und dann wird es halt, dann oft hat man dann

halt irgendwie Major-Version.minor

. irgendwie

Patch-Release oder so

und in den Patch-Releases sollten halt nur

Bugs gefixt sein, minor

sollte vielleicht kommen, vielleicht Features dazu,

aber es wird die

Abwärts-Komfortibilität nicht gebrochen und dann bei Major-Versionen

kann man halt irgendwie

eine neue App benutzen oder sowas.

Ja, kann man es halt inkompatibel machen.

Und oft sieht man das dann auch, dass Leute

das dann halt in, ja,

wenn sie halt ihre Abhängigkeiten definieren, dann so

reinschreiben, also alles, was größer ist,

größer gleich dieser meiner Version

zum Beispiel, sodass halt sie

kleinere Updates oder auch Features noch

bekommen oder halt alle Security-Patches, aber

halt nicht, dass die Kompatibilität

nicht gebrochen wird.

Nur das Problem ist natürlich, dass

tatsächlich garantiert ist halt auch ein Bugfix

kann natürlich die Kompatibilität brechen, wenn man sich

auch verlassen hat, dass sich etwas so verhält, wie es derzeit tut

und das aber ein Bug war.

Das ist natürlich insofern...

Ja, aber...

Bei 0.9.0.20, das ist auch super.

Ja.

Das gab ein sehr schönes Beispiel, das war

vor, ich glaube, einem Jahr,

vielleicht eineinhalb Jahren, zwei Jahren,

da hatte Flake 8 ein neues

Patch-Release rausgebracht.

Also die haben ja, glaube ich, von, weiß ich nicht,

0.96 auf 0.07 oder sowas

und haben da aber einen neuen Check eingebaut,

der nämlich gecheckt hat, ob F-Strings Variablen

enthalten. Und wenn du dann F-String ohne Variablen

hast, dann ist es rausgeflogen

und plötzlich sind halt dann bei diversen

Projekten geht die Pipeline nicht mehr

also ich hab da nichts geändert, was ist denn jetzt los?

War halt mit Star-Import einfach im

PIP-File und ja, blöd

Tja

Wie gesagt,

vielleicht hätte das schon vorher das überprüfen sollen

aber es war halt ein Bug und hat nicht funktioniert

haben sie den Bug repariert und schon

hast du auf einmal ein komplettes

komplett anderes Ergebnis und plötzlich ein Breaking-Change

in einer Pipeline, aber trotzdem.

Ja, dafür ist dann Push wieder ganz gut,

wegen der Log-File, wo es halt dann genau

die Penalties print.

Ja, ja, auch eben, weil

falls halt irgendwie andere Dinge,

also einfach um reproduzierbare

Umgebungen zu bekommen und auch

wenn jemand es schafft, irgendwie

malicious Pakete irgendwo hinzulegen,

das ist ja auch so etwas, was dann zumindest

sehr überprüft wird, dass der Herrscher stimmt und so.

Ja.

Würde dich auch nicht davor retten, wenn da schon ein malicious Paket drin wäre,

und was soll ich immer wieder erledigen?

Nee, das hast du schon verloren, genau.

Wenn es halt jemand später schafft, genau.

Ja, ja.

Ja.

Aber tatsächlich bin ich jetzt auch ein großer Freund,

dass ich eigentlich alle Abhängigkeiten,

die ich habe, wirklich fixiere,

weil ich bin da schon zu oft auf die Nase gefallen mit,

weiß ich nicht, irgendwie Celery,

das Monitoring-Tool Flower hat eine Abhängigkeit zur Tornado,

die haben im Bugfix-Release irgendwie

ein Attribut deprecated und rausgenommen

und plötzlich steht man dann da und nichts mehr geht

und das komplette Async ist tot.

Das ist halt bitter.

Ja, ist schon doof.

Ich habe gerade ein Problem mit einer Pipeline,

weil

das irgendwie so doof gebaut wird, dass da Abhängigkeiten

zu Docker drin sind, dass aber

das System dann doch abhängig funktionieren

muss. Also das heißt, wir nehmen dann, weil wir auf einer

Windows-Maschine das aufbauen müssen,

PyWin mit rein und das installiert

sich natürlich nicht auf der Windows-Maschine, weil das

dann in den Dependencies mit drin hängt. Das heißt,

ich muss in der Pipeline das Blockfile wegschmeißen.

Hätte man sich auch direkt sparen können.

Verlasten, dass man halt

das Dependency-Resolving vernünftig funktioniert.

aber naja, da muss man halt auch wieder dann manuell pinnen, aber das geht dann schon irgendwie.

Ja, aber solche Sachen, das ist halt wirklich hässlich dann, aber ja.

Da gibt es keine richtig gute Lösung für, ne?

Also wie baut man denn jetzt Python so zusammen, dass es immer vernünftig funktioniert,

immer wieder auch in zwei Jahren noch irgendwo und das ist ein bisschen blöd irgendwie.

Also auch wenn man jetzt, ich nehme jetzt noch dieses Windows-Beispiel,

wenn man jetzt da eine Executable erzeugen möchte,

denen man Leuten gibt, die eigentlich gar kein Python können oder auch Programmieren nicht können oder sowas,

sondern die wollen einfach ein Programm haben, was sie ausführen können, was dann auf Python läuft und bestimmte Dinge tut.

Das bei denen auf den Rechner zu bekommen, das ist gar nicht so einfach.

Aber darum gibt es ja auch Websoftware. Das ist ja genau der Grund, dass man diesen Knatsch halt nicht mehr hat.

Ja gut, aber es gibt ja auch da verschiedenste Lösungen, wie man irgendwie so ein großes Paket zusammenspült,

wo man dann alles mit reinpackt und die Dependencies mit reinpackt und den Compiler mit reinpackt und so,

dass das dann halt selbstständig irgendwie aufgebaut werden kann.

Ja, kann man schon. Also ich meine, PyInstaller ist halt wahrscheinlich vielleicht so die populärste.

es gab ja einige

NUCA, PyOxidizer

wir hatten ja auch schon ein paar Mal drüber

inzwischen, wenn man auf die Tools

guckt, das sind PyOxidizer und so

das ist schon wieder alles verschwunden

aus den Empfehlungen

hat sich wohl dann

PyInstaller ist irgendwie erstaunlich konstant

ja, aber ich habe es noch nie richtig

funktioniert einfach nicht so wie man will, wenn man zu viele

extra Dependencies hat, das ist auch nicht schön

ja

kein einfaches

Problem, leider

Ja, aber

was macht man da? Also Paket bauen?

Ja, du sagst Web-Anwendung.

Ja, Web-Anwendung. Oder ich meine, klar, Docker-Image dürfte

schon relativ haltbar sein.

Ist natürlich so ein bisschen verschwenderisch.

Solange es Docker noch gibt.

Ja.

Ja.

Aber,

tja, ich habe auch keine

Lösung dafür. Meine Lösung ist,

nicht auf Systemen unterwegs sein, wo das

ein Problem ist.

Es gibt halt Leute, die halt andere Systeme nutzen,

das ist ja klar und wenn die darauf

relyen und wenn man von bestimmten

Konzernen, die halt dann bestimmte Policies haben

die man nicht verstehen muss, aber wo man das natürlich

dran halten muss. Die haben bestimmt 1998

Sinn gemacht, dass die jemand eingeführt hat.

Ja, also die sind auch veränderungsresistent

also da würden ja ganze Abteilungen sich als

Renewant erweisen vielleicht

aber wenn die so lange nicht gut verdienen, ist das halt

nicht notwendig, da irgendwas zu ändern

das ist halt dann so.

Ja, aber wie gesagt

also nochmal zur Versionierung zurück

ich mache tatsächlich auch dieses Semantic Versioning

Man kann halt damit wenigstens versuchen, dass man halt dem Nutzer, den man ja meistens nicht kennt, so ein bisschen den Pain zu nehmen, wie man mit Updates umgeht. Weil jedes Update, je nachdem wie groß das Projekt ist und auch wie stabil das Projekt ist, Stichwort Testing und sowas, kann das ja auch mit ziemlich viel Kopfzerbrechen verbunden sein, irgendwas überhaupt hochzuziehen.

und bei dem habe ich

jetzt halt gesagt, hey, wir machen ein Semantic Versioning

und da versuche ich mich auch sehr dran zu

halten, also darum habe ich jetzt auch schon in

den Jahren jetzt vier

Major Releases gemacht, weil

Python halt irgendwie komplett alles auf drei umgestellt ist,

halt ein Breaking Change, muss dann hochgehen, da kommt es halt nicht

drum rum. Fühlt sich manchmal so ein bisschen

verschwenderisch an, wenn man denkt,

schon wieder, das ist nicht so viel Code, aber

ja, und man kann halt

einfach nur hoffen, dass man es den Leuten halt möglichst einfach

macht, weil das Problem ist, da sitzt dann nachher

am anderen Ende der Welt jemand, der möchte genau das Package verwenden oder nutzt es im schlimmsten Fall vielleicht schon

und dann macht man ihm plötzlich was kaputt, der hat keine Chance, das irgendwie vernünftig zu erreichen,

zumindest nicht direkt und da sollte man

schon gucken, dass man das so stabil wie möglich baut.

Ja.

Ja, ist auf jeden Fall nett.

Ich glaube, manchmal machen Leute auch so ein bisschen zu viel

Google Schwurbel um, es muss

backwards kompatibel sein für

bis in alle Zeiten.

Ich finde es vollkommen okay zu sagen,

das Ding geht jetzt kaputt, wenn du das so nutzt wie vorher,

aber die müssen es halt wissen.

Es wäre schon nett, wenn man die

Versionsnummer dann vielleicht Major ändert.

Wenn jemand halt blind irgendwie drei

Majors hochgeht und sich dann ärgert, dass es nicht geht,

ja gut. Wie gesagt,

ich meine, manche Projekte haben ja leider wirklich kein

Change Log oder so ein ganz rudimentäres.

Da ist man wirklich angeschmiert, weil du kannst es halt nicht wissen.

Wie machst du das Change Log und wie schreibst

auf, schreibst du dann vor jedem Commit oder lässt du aus den Commit-Messages automatisch dein Login?

Ich mache das tatsächlich zu Fuß. Also da gibt es ganz viele Tools.

Ich fand das Stand irgendwie nicht dafür, weil wie gesagt, wenn ich irgendwas

mache, dann weiß ich ja, was ich mache und dann kann ich es auch einfach kurz ins Change-Logger.

Es ist einfach ein Markdown-File.

Es ist clean, vernünftig, deine Arbeit zu dokumentieren.

Ja, und vor allem, das sind ja auch Stichpunkte. Ich meine, inzwischen habe ich Dokumentation, da kann ich gleich noch was dazu sagen.

Auch ein Thema für sich.

aber

also ich habe einfach ein Markdown-File

und da ist halt, das ist halt eine lange Liste, wo

dann halt drin steht, hey, am so und sovielten

habe ich diese Version released und das hat sich geändert.

Ich habe da irgendwie, weiß ich, drei Rechtschreibfehler

in der Dokumentation gefixt, die Funktion ist neu

und die Funktion hat neun Parameter.

So und dann, das ist halt, das dauert eine Minute,

das zu schreiben, ich weiß ja, was ich da tue.

Und wenn ich jetzt sage, ich sammle ein paar Kleinigkeiten,

wo es sich nicht lohnt, ein Release zu machen, weil ich es gerade nicht so dringend

brauche, dann habe ich halt einfach so ein

Current, temporäres Ding

oben drin stehen und dann, wenn ich halt

fertig bin, dann sage ich, okay, das gebe ich

dem Namen, also sprich eine Versionsnummer und dann

habe ich die Sachen einfach schon zusammengeschrieben,

wenn von mehreren Seiten was, oder wenn mal

auch von Kollegen oder so ein Pull-Request reinkommt oder

sowas.

Das ist auf jeden Fall ordentlich.

Also ich tatsächlich

bin da halt einfach gebranntes Kind, weil ich es halt schon

zu oft hatte, dass ich denke, ja kacke, kann ich das

noch verwenden, kann ich es nicht verwenden so?

Also ich frage mich gerade, ab wann ich mit sowas anfangen würde,

weil ich würde jetzt zum Beispiel in der ursprünglichen

Entwicklung jetzt damit noch nicht anfangen, ChangeDocs zu schreiben, wenn ich

jetzt noch nichts habe, was richtig fertig ist und was funktioniert.

Wahrscheinlich bei Person 1.0

würde ich sagen.

Oder sobald halt Leute anfangen, das zu verwenden.

Was du natürlich auch nicht so genau weißt.

Ja, sobald du was

einigermaßen Nutzbares irgendwie hast.

Ja, genau.

Ja.

Ja, ja.

Ich mache das,

ja, ich überlege gerade, ob ich weiß, was ich so mache.

Und dann denke ich mir so, oh nein, ich breche es drauf und die kommen

an die Schulzeit.

Ich meine, es kommt doch immer darauf an, wenn das halt so ein Mini-Ding ist, also gut, selbst das kann irgendwie an eine zentrale Stelle eingebunden sein, aber zum Beispiel jetzt das Package, an dem ich jetzt arbeite, das ist halt eigentlich, das ist halt so eine Toolbox und ich bin eigentlich gar kein großer Fan, dass man so diese, sagt, hey, hier ist so ein Haufen von Zeug, das du so querbeet in dein Projekt einsetzen kannst.

Der Werkzeugkoffer bräuchte ich im Schrank. Da hängt auch alle möglichen

Schraubenschlüssel rum. Jeder hat seinen eigenen Werkzeugkoffer

mit eigenen Schraubenschlüsseln.

Da tauscht man zu selten aus.

Da sind aber die Farben, die hat man sich selber zusammengesucht.

Man weiß selber, wo man in der Kiste was findet.

Aber wenn jemand anders an diesen Werkzeugkoffer reinguckt, dann...

Ja.

Ich finde es eigentlich cooler, wenn man das...

Ich meine, da muss es nicht auf JavaScript-Level gehen,

wo jeder zwei Zeilen ein eigenes Package ist.

Das ist manchmal ein bisschen krass.

Aber wenn man die Sachen vielleicht auch ein bisschen...

Sagt man so, würde ich jetzt das Package nicht geerbt haben,

sondern würde es jetzt neu machen.

und sagen, hier dieser Code, der soll irgendwie Packages,

würde ich das wahrscheinlich nach gewissen Use Cases

strukturieren.

Das ist ja auch so ein Klassiker,

das haben ganz viele Firmen.

Ganz viele Firmen haben ein Paket, das heißt so wie die Firma.

Oder sie haben halt ein Paket, das heißt dann

irgendwie wie die Firma plus Core.

Das heißt halt Core.

Das ist ganz, ganz typisch.

Aber wie gesagt,

ich habe irgendwie ganz viele Sachen gebaut,

die mir bei Unit Tests helfen.

Dann würde ich sagen, hey, das ist dann jetzt das

Ambient Unit Test Paket oder so.

und dann alle Sachen, die haben irgendwas berechnen oder die irgendwas mit dem View-Layer zu tun haben,

weil viele Projekte laufen bei Django inzwischen auch headless,

das hat dann auch gewisse Dependencies, die man ja sonst nicht reinholen muss,

das ist dann auch nur das ein eigenes Paket.

Ich habe das jetzt mit Extensions tatsächlich gemacht,

weil am Anfang war es auch so, dass auch die ganzen Dev-Dependencies wurden alle mit installiert immer,

weil damals mir gar nicht so bewusst war, dass man das irgendwie trennen kann.

Ich habe das dann einfach irgendwann übernommen und so ein bisschen umstrukturiert

und dachte, okay, cool, funktioniert, wird schon passen.

aber man kann ja tatsächlich sagen, dass man

verschiedene Extensions macht, also das kennt man, wenn man

das aus dem Requirements

oder so, das ist so eine eckige Klammer, wo dann irgendwie

bei Celery kann man es mit SQS oder mit

Rabbit oder keine Ahnung welchen Extensions installieren

und da kann man natürlich auch sehr schön

die Dependencies wegkapseln, weil du kannst zum Beispiel sagen

hey, also zum Beispiel in meinem Fall ist

es jetzt, ich habe diverse Sachen, die halt nur

fürs Django Template Layer interessant sind,

also ein Middleware und sowas und da sind halt

ein, zwei Dependencies drin, die ich in anderen Cases nicht brauche.

Das heißt, ich kann einfach hingehen

und sagen, hey Leute, also die ist dokumentiert,

sagt, hey Leute, das ist das Standardpaket, das ist so

das normale Shit, den man so mit Django machen

kann und wenn ihr jetzt

irgendwas spezielles Julia haben wollt, das ist

hier dokumentiert und dann müsst ihr halt noch

die Extension mit installieren und dann kriegen die halt

auch die

Penalty.

Ja, das ist halt auch die Frage, bietet man den Leuten direkt

das volle Rundum-Sorglos-Paket an, dass die ja nicht

so viel Aufwand haben und das alles lesen müssen und

alles nachinstallieren müssen oder

macht man das halt sehr modular?

Also ich sag mal so,

und Jochen unterhalten sich über die Programmiersprache Python

Sachen sonst nachher in so ein Projekt rein, die man eigentlich gar nicht

haben möchte.

Genau, ich habe jetzt hier gerade nochmal

das letzte Paket, das ich irgendwie

gebaut habe, reingeguckt.

Das ist Django Fire Response.

Oh, da hast du auch in deinem Stream

einiges dran gearbeitet. Genau, da habe ich

jetzt bis letzte Woche noch was dran gemacht.

Falls ihr es noch nicht mitbekommen hattet, in der letzten Folge hatten wir

erwähnt, dass der Jochen jetzt nämlich auch streamt.

Relativ häufig und da könnt ihr zugucken, was der die ganze Zeit

für Unsinn anstellt und wie man dann so entwickelt,

wie man das sein macht.

Ich finde es eigentlich, es sieht cool aus.

und ja, wirklich.

Danke, danke, danke.

Genau, ja, technisch gar nicht so schlecht, glaube ich.

Inhaltlich muss ich noch ein bisschen feilen, glaube ich.

Nein, andersrum, weil ich finde auch tatsächlich, dass es inhaltlich

interessant ist, was man da alles so umsetzen kann.

Ich baue das gerade so ein bisschen nach, ehrlich gesagt.

Also, Feilresponses fand ich sehr interessant.

Ja, also, wo ich

tatsächlich noch Schwierigkeiten, ich merke das, das habe ich auch heute wieder

gemerkt, tatsächlich, was mir

schwerfällt und was ich nicht so gedacht hätte, nicht erwartet hätte,

also, wenn ich irgendwie so

an den Projekten rumentwickle und ich

weiß aber, das können sich Leute

nachher angucken, dann tendiere ich dazu zu sagen,

so, ah, jetzt gut, jetzt müsste ich

da jetzt mal tief graben oder irgendwie

versuchen rauszukriegen, das wird voll langweilig und ich muss

ganz viel probieren und ich habe absolut keine Ahnung, ob ich damit

irgendwie eine halbe Stunde fertig bin oder so und jetzt

kann es sein, dass sich Leute einfach eine halbe Stunde lang

fürchterlich langweilen und es ist

fruchtlos und dann, also das

merkt man, weil normalerweise würde mir das halt

nichts ausmachen, mir macht das ja Spaß,

und dann probiere ich halt rum und wenn es

halt geht, super, wenn es nicht geht, naja.

Also ich muss sagen, also mir macht das dann auch Spaß, weil dieses Rumprobieren,

das kriege ich dann ja mit und da lerne ich auch

mal was bei und ich glaube gerade dann, wenn man halt nicht

alles so perfekt vorher schon weiß,

sondern es so ein bisschen rausknobeln muss und man ist ja quasi

mit live dabei, das ist ein bisschen vielleicht wie ein Podcast,

durch dieses rausknobeln, das du ja

dann machst, dann knobelt man selber so ein bisschen rein

und man kommt halt tiefer in die Thematik rein

und man hat ein tieferes Verständnis für die

Zusammenhänge und das ist unheimlich wertvoll

dann, deswegen sollte man das auch so tun.

Ja, das ist tatsächlich vielleicht eine interessante Geschichte,

dass man genau dabei Leuten halt zuzutun,

aber wenn man das macht oder

für mich war das überraschenderweise so,

und Jochen unterhalten sich über die Programmiersprache Python

selber kurz draufdrücken, dann hast du einen

großen, sensierten Teil, dann kannst du wieder freischalten

und dann, okay, geht wieder.

Ja, genau, wird sich schon

irgendeine Methode finden. Kennt ihr das aus

Starship Troopers, wo es dann kurz diesen Zensur-Python gibt und in den Hintergrund

werden die Kühe dann zu den Elfen gegessen?

Ja, und hinten werden die Gedärme fliegen, genau.

Ja, das stimmt.

Das ist eine gute Idee.

Da fliegen noch nicht genug Gedärme in dem Stream.

Das ist wahr.

Genau, da habe ich ja dieses Django

FireResponse-Paket gebaut.

Da habe ich etwas verwendet, was ich jetzt vielleicht dann

auch nur aus Spaß

habe ich

MBDev, was in der Data Science-Welt

so ein bisschen verbreitet hat.

Vielleicht nochmal ganz kurz, das hast du auch schon mal

erklärt, aber MBDev ist quasi entwickeln mit dem

Notebook, aber das Notebook quasi

das bei dem Paket automatisch mit den Dokumentationen

und so erzeugen kann. Genau, also das

eigentliche Ding, was das so interessant macht, ist, dass man

so ein bisschen Literature Programming

machen kann und halt Dokumentationen,

Code und Tests irgendwie

direkt zusammenstehen hat.

Und daraus dann halt sozusagen aus den Notebooks

wird dann das Paket erzeugt

oder das Modul, also der Source-Code

erzeugt und

aus dem Source-Code wird dann ein Paket gebaut

und das geht auch tatsächlich, ich habe jetzt nochmal nachgeguckt, weil ich

es gar nicht mehr wusste, aber ja, das macht das per

Setup.py und da hat

man halt auch eben

da schreibt man halt rein

extra Require

zum Beispiel und

kann dann halt, das sind einfach

und Dict und dann kann man da beliebige Dinge reinschreiben.

Zum Beispiel, was ich jetzt da nur drinstehen habe, ist halt

Dev und dann Dev Requirements, aber man kann halt

auch eben alle möglichen optionalen

Geschichten mit angeben, die man dann halt installiert oder nicht.

Und da wäre es zum Beispiel so,

dieses Django File Response-Dings hat selber praktisch

keine Abhängigkeiten,

aber wenn ich jetzt

die Dev Requirements da mit reinnehmen würde,

dann wäre das ziemlich übel,

weil dann würde der ganze NBDev-Kram mitkommen,

zum Beispiel. Es würden

Jupyter Notebooks mitkommen, es würde Pandas mitkommen, es würde

NumPy mitkommen, es würde irgendwie so

das halbe Deadline-Unternehmensumgang mitkommen.

Ja, und auf dem Web-Server hast du, wo du das Django verwenden willst, hast du das ja gar nicht.

Und plötzlich wird dann wahrscheinlich irgendjemand da vor einer Konsole sitzen und denkt sich,

warum kommt da jetzt ein Fortran-Compiler mit?

Und warum dauert das eine halbe Stunde, bis das kompiliert ist?

Ja, genau.

Nicht so gut.

Aber vielleicht noch mal kurz zur NBDEV.

Wie baut man denn quasi sein normales Notebook in ein NBDEV um, damit es halt dann auch als Paket...

mit.

Muss ich da quasi ein anderes Notebook nehmen

oder kann ich einfach Jupyter Notebook nehmen?

Das ist Jupyter Notebook, aber das einzige,

was man da braucht, ist im Grunde

dieses, man muss

mbdev installieren und dann halt mbdev

build lib und dann hat man so ein paar

Metaanweisungen

sozusagen für mbdev in dem Notebook selber.

Das heißt, das ist eine Extension für das eigentliche Notebook

und wo man dann quasi ein bisschen anders strukturiert,

als man das macht?

Das ist keine Extension, sondern es liest es einfach nur.

Und wenn man da sowas

reinschreibt wie Kommentar und dann Export

oder Default Export.

Diese Sachen werden dann ausgewertet

und werden dann benutzt, um dann daraus

zum Beispiel die Python-Module zu erzeugen.

Also es ist

nicht mal irgendwie ein

Jupyter-Plugin oder sowas.

Das heißt, man muss einfach richtig seine Zellen vom

Typ her definieren im Jupyter-Notebook und

dann Docs hinschreiben.

Und das schreibt dann halt den Source-Code dann raus.

Okay.

Also ich fand es eigentlich ganz nett.

Ich finde das sehr spannend. Also es ist sehr cool.

Ich benutze auch relativ viele Notebooks zum Entwickeln.

Also gerade auch so Django, so IO-Sachen

oder Modellsachen, Funktionen,

Methoden.

Die kann man einfach super schnell dann testen. Die gehen halt an,

Django schnell auf und dann kann man testen.

Ich mache das tatsächlich, das haben wir aber auch beim

letzten Mal, als ich bei euch eingeladen war, schon mal drüber gesprochen.

Ich mache das tatsächlich so, dass

ich das sich oft mit dem Debugger

entwickle.

Ja, das ist auch eine Option.

Das mache ich nicht so oft, aber

das wollte ich mir auf jeden Fall auch nochmal angucken.

Du benutzt ja auch PyCharm.

und das ist, glaube ich, sehr komfortabel.

Man muss sich auf jeden Fall abgewöhnen,

STRG-S zu drücken, weil dann

speichert ihr die Datei und dann fliegt ihr lieber raus.

Aber ich finde, das ist

eigentlich ganz cool, vor allem wenn man

so viele Funktionen und

irgendwie externen Daten

und sowas bekommt, wo man dann oft, okay,

da muss ich mir auf die dritte Array-Stelle zugreifen,

du weißt, es ist da irgendwo, du weißt

nicht genau, wo es ist und da macht man

normalerweise viele Runden und das ist dann einfach angenehm,

wenn du dann direkt einfach

in diesem Evaluate-Expression

einfach die Sachen da zusammen klopfst und dann direkt auf den Knopf drückst

und weißt, jo, läuft, passt.

Ja, das muss ich auch wieder in den Land sprechen.

Das geht auch in anderen Entwicklungsumgebungen

tatsächlich ganz gut, wenn man die richtig

einträgt.

Das haben wir so ein bisschen gefummelt, weshalb man halt

den Debugger halt so laufen hat, wie man das gerne hätte.

Aber hast du da schon diesen Debugger, den wir

letztes Mal vorgestellt haben,

gesehen? Und zwar

Kodo, oder wie hieß der? Kodo App?

Kodo App, genau. Das ist ein neuer

Dango-Debugger, der

relativ coole Sachen machen kann, wie Visualisierung

der Code-Pathes und sowas. Cool.

Relativ geil, müssen wir schauen. Ist aber nicht für Python.

Ja.

Ja, aber das wäre auch auf jeden Fall

genau, also das habe ich mir auch zum Ziel gesetzt.

Ich meine, normalerweise benutze ich ja immer Vim oder so,

aber das eben jetzt mal explizit

nicht zu machen, sondern im Stream halt

versuche ich jetzt, zum Beispiel habe ich jetzt immer eher

VS Code benutzt.

Einfach nur, um das halt auch so ein bisschen

zu lernen. Oder halt auch PyCharm würde ich auch

auf jeden Fall machen. Ja, also, ach so, was du auch

noch dabei machen solltest.

Vielleicht ist so ein bisschen so die Konfigurationsteilung, ein bisschen so die Magie

zeigt, wie man das Tool dann jeweils benutzt.

Das ist, glaube ich, auch nochmal sehr lehrreich. Also vielleicht kurz

darauf eingehe ich so, wie man es

danach macht. Kann ich mir einfach mal vornehmen,

das zu versuchen zu verwenden.

Je mehr man halt neue Sachen lernt,

die man noch nicht lernt.

Ja, okay,

ich werde es mal versuchen.

Ja, ja.

Ja, das ist schon richtig. Man muss einfach ab und zu mal

Dinge ausprobieren.

Ja, stimmt.

Ja, wenn man sonst immer noch bei seinen Sachen bleibt, dann wird man darin auch ein bisschen besser, aber was neue Sachen ist schon spannend

Ja, oft sowas wie Programmieren oder sowas kann ja auch für einige Leute neu sein

Ja, eigentlich bin ich schon fast zu lange dafür dabei, um das nochmal zu erzählen, aber ja, ist noch wahr

Das Gefühl geht auch nicht weg

Ja, okay, man hat halt von allen Sachen immer keine Ahnung, aber irgendwie hat man dann doch mehr Ahnung hinterher, so Rückblicken von einigen Sachen, die man eigentlich gar nicht wissen wollte

Aber so da vorne ist immer der Berg wird immer gr anstatt kleiner das ist so ein bisschen das Problem Ja wei nicht was mir zu zunehmender Erfahrung auff ist oft muss ich gar nicht also was mir heute leichter f oder der Unterschied zwischen heute und

den Zeiten, wo ich halt wenig Erfahrung hatte, war halt,

ich hatte früher immer mehr das Gefühl,

bewusst Dinge zu tun oder bewusst irgendwie Sachen

auszuprobieren. Und heute muss ich

eigentlich nur, denke ich mir so, okay,

ich habe keine Ahnung, wie genau es passieren wird, aber

irgendwie in der nächsten halben Stunde wird mir schon irgendwas

einfallen. Und dann bin ich halt da rum und dann hinterher

denke ich so, okay, das war es, aber keine Ahnung, ich weiß gar nicht,

und Jochen unterhalten sich über die Programmiersprache Python

neben den Seiten des Packages steht und dann

einen Bug hat, beziehungsweise auch

irgendwie so ein gewisses Maintenance machen muss, zum Beispiel

gibt es eine neue Dango-Version und man wird dann inkompatibel,

das passiert ja leider immer wieder mal

und das ist tatsächlich auch

eine Sache, dass wenn man

so ein Package in die Welt setzt, ich nehme jetzt mal

extra dieses Wort, dass man

halt da schon ein bisschen im Kopf behalten sollte,

wie gehe ich denn damit um mit der Maintenorship?

Also wenn man sagt, ich mache das jetzt für mich, mal zum Ausprobieren,

das nutzt eh keiner. Ich suche immer noch kurz

den Übergang von der Dusche, aber okay, du bist für

ein Maintenorship, ja.

wegen Bugs und Problemen.

Ja, gerade, wie lange man darüber nachdenken sollte.

Genau.

Und das ist tatsächlich

auch eine Sache, das merke ich

halt auch oft, dass ich halt vor allem in älteren Projekten,

die ich habe, dass ich da halt ein sehr cooles Package

verwendet habe, würde ich heute nicht mehr machen,

aber ich habe halt den Code so gebaut, dass es halt funktioniert.

Und dieses Package ist halt irgendwann mal hart

abandoned worden, also dass dann wirklich die Leute

einfach kein Interesse mehr daran haben.

Also die dann nicht mal mehr das Interesse haben, zu sagen,

hey, ich schreibe einfach

sorry, ich weiß nicht, bin jetzt irgendwie Gärtner und ich mache kein Programmieren mehr,

kann ich nicht helfen, sondern es einfach kommt gar nichts mehr,

obwohl die Leute halt immer noch aktiv sind.

Also man kann es ja auch sehen, was Leute so machen.

Mir ist halt immer wieder sehr ärgerlich und ich glaube, dass wenn man so ein Paket in die Welt setzt,

dann man irgendwann merkt, okay, ich habe jetzt den Fokus verloren und das nutzt aber vielleicht noch irgendwer.

Ich glaube, das Erste, was man machen kann, ist halt, dass man irgendwo Prominenten im Möglichen hat,

dass den Leuten das Feedback geben können.

Also offensichtlich ist es einfach bei GitHub die Issues.

wie kann man übrigens auch sehr schön über die

zum Beispiel SetupPyodot oder

ProjectSetupTommel direkt verlinken

in PyPy, das wird direkt

in das ChangeLog und so kann man alles perfekt verlinken,

dass die Leute gar nicht lange suchen müssen.

Und dass man dann auf jeden Fall Leuten, die das halt nutzen,

die Möglichkeit gibt, dass sie Feedback geben.

Also zum Beispiel, ich habe die ersten zwei Issues bekommen

tatsächlich mit Übersetzungen, weil halt

in dem Package halt ein paar

Models, die ich da bereitstelle, waren halt auf Deutsch,

weil die meisten Projekte, die wir nutzen, sind halt auf Deutsch.

Und es ist halt nicht aufgefallen, dass da der Übersetzungshelper

fehlt. Und das war dann

für die Leute halt echt super ärgerlich, weil die halt das irgendwie nutzen

wollten. Wahrscheinlich haben die Blog-Artikel von mir gelesen,

weil dann so, ja Mist, in dem Projekt ist alles auf

Sprache X und das plötzlich auf Deutsch.

Wenn der gut anslät, dann kommt irgendein unteren raus.

Genau, und das hat mich

dann total gefreut. Es kam auch direkt ein Podcast hinterher,

hey, hier so und so, und hab dann auch die Übersetzung nachgezogen

und alles super. Also,

hätte ich sonst niemals rausgefunden, weil bis die irgendwie

die Webseite irgendwie mich anonym

anschreiben oder mich über LinkedIn suchen oder keine Ahnung

was, ist das ein riesen Overhead und so. Einfach

kennt halt jeder, ist schnell gemacht und

das ist, glaube ich, so ein kleiner

kleiner Convenience, die man dann

seinen Usern irgendwie bereitstellen kann,

weil es kostet ja auch nichts, das ist ja schnell gemacht.

Und wie gesagt, das andere mit der

Metaindership, wenn man halt wirklich sagt,

okay, ich gebe das jetzt auf,

es gibt ja so, entweder so

Projekte, so wie Jazzband oder sowas, da gab es

noch in der DjangoCon einen schönen Vortrag dazu,

wenn das wirklich ein größeres Projekt ist, dass man die da einfach abgeben

kann und sagen kann, hey, sorry, ich bin raus

hier mit dem Kram, aber das nutzen noch Leute,

bitte kümmert euch drum.

Und auf der anderen Seite,

dass man natürlich auch dann notfalls auch andere Leute

einfach befördern kann und einfach

sagen kann, hier

das,

also ich habe jetzt im Interesse und ich muss das reparieren

und sage, gut, ich habe selber keine Zeit, dann ach halt,

ist immer noch besser, wenn es gar keiner macht.

Ja,

ist ja gar nicht so einfach, also gerade bei Leuten, die halt

for pleasure entwickeln,

da muss man sich halt auch überlegen,

will man nicht auch mal was Neues machen oder sowas,

dann ist das schon klar, dass das schon schwierig ist,

immer an den alten Sachen die irgendwie so mitzuschleppen.

Aber das ist ja oft, also bei mir ist das keine

bewusste Entscheidung, sondern das ist ja so,

und so.

auch anstrengend.

Welche Größe du hast irgendwann.

Das kann auch sehr overhelming werden.

Das Leben von Leuten ändert sich ja auch oft.

Also Situationen oder sowas.

Wenn da irgendwie dann die

Prioritäten sich privat verschieben und die Leute dann nicht

mehr von morgens bis abends dann noch in ihrer Freizeit

partizipieren können, dann...

Ja, absolut. Ich meine, das ist natürlich ein Problem.

Es hat ja auch Carlton Gibson, glaube ich,

macht gefühlt jede zweite Jungle Corner einen hervorragenden Vortrag

zu dem Thema.

Das ist natürlich ein Problem, aber

ich sage, es gibt halt relativ einfache Möglichkeiten,

die zwingend natürlich nicht bei jedem zutreffen

wenn einer wirklich sagt, hey ich habe es

im Beruf gewechselt oder ich bin weggezogen oder keine Ahnung

was und habe meinen GitHub Account geschlossen

das war es jetzt für mich, okay kann immer

passieren, aber ich sage eben in meisten

Fällen ist es wahrscheinlich oft, dass

Leute noch irgendwie latent am Ball bleiben

und da gibt es halt ganz einfache

Wege, das Problem zumindest für einen selbst

irgendwie zu lösen.

Ja, ich sage mal so, es ist schon schön, wenn man halt so ein paar Issues irgendwie

nicht die größten nicht offen lässt

sondern zumindest ein Team findet, das dann Lust hat

wenn man gerade wirklich viele Leute hat, die dann

was benutzen, dass denen halt wenigstens mal

deren Pull-Request-Merch oder denen die Möglichkeit gibt,

dass sie selber Sachen merchen können, also die Interesse

dann haben. Ich meine, klar kann man auch einfach forken

und dann irgendwie ein neues Package machen und sowas, aber

es ist halt

natürlich schon schön, damit das alles irgendwie ein bisschen

zentralisiert ist, aber ja.

Aber die Jazzband hast du ja erwähnt, das ist glaube ich eine ganz gute Möglichkeit,

das zu tun, ja?

Ja, ja, da bin ich

jetzt, ach, naja, da hat sich da letztes Mal auch was

getan, da bin ich jetzt auch mal da beigetreten.

Aha, cool.

Und dann, weil ich habe mich gesehen in dem

Projekt, an dem ich momentan gerade da rumschraube.

Da habe ich diverse Geschichten, die in Jasmine

drin sind, reingewendert.

Sozusagen, damit ich die

anpassen kann und eigentlich

kann ich das ja auch dann einfach so machen vielleicht.

Einfach direkt, ja. Cool.

Cool. Dann löst du quasi

dein Problem und hilfst aber noch ganz

vielen. Genau. Ja, gut.

Vielleicht mache ich auch demjenigen, der dann die

nächste Release baut, Kopfschmerzen. Das kann

auch sein.

Aber ja, mal schauen.

Ist auf jeden Fall interessant.

Das ist ja vielleicht auch eine kleine Verbesserung

Ja, ja

Ja

Tja, was haben wir denn

Was gibt es denn noch so für Dinge, die wir

über Paket-Ding

irgendwie erzählen sollten

Habt ihr irgendwie

also habt ihr irgendwelche Tools

die ihr bevorzugt verwendet, also Flit

Okay, kann das ihr jetzt nicht, hab ich auch nicht

Werd ich dann demnächst mal ausprobieren, mal gucken

Ja, ja

Ja, Poetry

verwende ich meistens,

aber... Ja, tatsächlich, so zum

normalen lokalen Verwalten schon, zum Bauen.

Du verwendest pipenv,

aber das ist nur für die...

Genau, nur für die Requirements

oder Logfile. Ja, genau.

Tatsächlich,

das Package, das

schiebe ich noch mehr oder weniger genauso hoch, wie

das damals 2012 war, also so eine ganz

fiese Set, also das heißt fies, aber aufgeräumt ist sie

aber eine sehr angestaubte Setup-Pi.

Setup-Pi, ja.

und ja, dann auch, ich baue da auch ein Wheel draus, weil das für, also ich selbst bin ja tatsächlich ein Windows-Nutzer,

das wird jetzt auch ein bisschen populärer, aber wieder beim Coden, aber tatsächlich ist das mit den Wheels sehr, sehr angenehm,

weil die Sachen sich einfach alle installieren lassen und man da keinen Knatsch mehr hat.

PyCurl ist aktuell mein einziger Endgegner, wenn ich das installieren möchte.

Aber genau, von daher, das habe ich mir aber auch aufgeschrieben.

und der

wie Entwickler das machen und das erinnerte mich

jetzt gerade daran, ist halt, dass sie irgendwann mal

sich damit beschäftigt haben und dann haben sie ein Setup

für Wi-Fi geschrieben und das kopieren sie halt

Projekt von Projekt zu Projekt immer weiter.

Das Problem ist halt

sozusagen aus

Infrastruktursicht dann, ja, Abwärtskompatibilität

ist halt super wichtig,

weil es

sind halt oft viele Dinge immer noch im Einsatz,

die von irgendwann an und dazu mal kopiert

worden sind. Das heißt, man kann die Abwärtskompatibilität

nicht mehr brechen, weil ansonsten bricht ganz

ganz viel, ganz, ganz viele Dinge

und dessen

Vorschlag war auch eher

SetupCFG zu verwenden

und dann halt auch mal, oder irgendein

Projekt-Template oder so, oder eben ein Tool,

was einem das halt abnimmt.

Das klingt aber auch alles schon

wirklich, also ganz im ganzen Packaging-Ding,

so gordischer Knoten. Ja, das ist

wirklich gemein. Ich meine, was will man machen, wenn du

ja, ein Großteil der Pakete

da draußen verwenden halt uralte Geschichten

und du kannst es nicht mehr ändern, weil wenn du es änderst, dann

brichst du all die Pakete. Ja, wegschmeißen, neu machen,

auf Features verzichten, vielleicht braucht man die alle gar nicht.

Ich habe das wesentliche

konzentriert.

Ja, genau, ich habe auch einmal so ein

Cookie-Cutter-Template verwendet, also es gibt ja auch

Python-Package

Cookie-Cutter-Template

von...

Genau, und das

fand ich auch ganz nett, aber...

Der übrigens auch auf Twitch streamt.

Ja, ja, richtig, genau, das habe ich mir

auch schon

auch ein bisschen angeguckt.

Genau, fand ich auch gut.

Was ich auch ganz interessant finde,

apropos

Projektsetup,

der Code, der

jetzt in meinem Package drin ist, der ist natürlich

auch logischerweise getestet.

Am Anfang war nicht so viel getestet.

Inzwischen ist er getestet.

Zumindest Großteils.

Die Sachen, die ich halt tatsächlich nutze, die sind jetzt auch getestet.

Und am Anfang war es auch so,

dass diese Testfiles dann

einfach mit in dem Package gebundelt wurden.

Also die

Metatests quasi, also die Sachen, die das Testen

sich nachher ausliefere, mir ist dann nachher mal aufgefallen,

die muss ich ja gar nicht mit ausliefern, weil das

interessiert einfach keinen. Also ich meine,

vielleicht ist es doch, weil die wissen wollen, ob ich vernünftig

das abgedeckt habe, aber eigentlich liefere

ich eine Datenmenge aus, die eigentlich nichts mit der

eigentlichen Funktionalität zu tun hat.

Und das war für mich so der erste

Erkenntnispunkt, also sollte man mal reingucken,

wie das damals mal irgendwie strukturiert hat, weil

da kann man nämlich auch einstellen, welche Dateien dann

von diesem Bundler gefunden werden sollen.

und Jochen unterhalten sich über die Programmiersprache Python

ausschließend hat, aber

ja, die kleinen Hürden.

Das ist auch eine der häufigsten Sachen,

wenn man so, oder wie mir passiert,

wenn man so eine Git-Action-Pipeline hat,

die halt auch testet und so,

das lokal funktioniert alles und dann macht man

einen Push und dann geht die Pipeline kaputt und dann sagt man,

hä, warum? Und ja, ganz oft ist es halt,

weil in den Dev-Requirements irgendwas drin war,

was man halt tatsächlich gebraucht hat, aber dann in den Produktions-

Requirements nicht mehr und dann...

Ich würde sagen, fast besser als andersrum,

weil dann fällt es einem ja direkt auf und dann kann man es einbauen.

Das ist wahr. Dafür sind ja Pipelines

dann auch da oder dann die E-Mail-E-Mail kommt,

dass das schon wieder kaputt gegangen ist oder so.

Ja, ja, ja.

Das ist ja ganz praktisch.

Stichwort Pipelines.

Ja.

Hatten wir ja auch im Vorfeld noch drüber gesprochen.

Was ja bei GitHub sehr, sehr cool ist,

sind ja diese Travis-Matrizen,

wo man, ich glaube, Travis ist das Richtige, ne?

Kann sein, ja.

Ja, die Tox-File, genau.

Und Travis nutzt das dann.

Man kann da einstellen,

wie viele verschiedene Python-Versionen das einmal durchdauert.

Genau, mit welchen Django-Versionen

und dann kann man halt relativ simpel

in so einer Art YAML-Datei, glaube ich, ist das,

kann man dann halt eingeben

und sagen, okay, ich unterstütze explizit

Python 3.6.

Genau, gehe ich durch und dann

halt mit der und der Django-Version, da baut er dann eine Matrix auf

und testet halt wirklich die Sachen gegeneinander

durch und das ist halt sehr cool, weil auch wieder so eine

Sache, man kann in der Setup oder wie auch immer

man sein Projekt Meta deklariert, kann man

halt auch explizit angeben, welche Django und Python

oder was auch immer Versionen

man unterstützt. Also ich bin ab 3.8

und 3.2.

Ja.

mit dieser Matrix, gibst du die Sachen halt einfach ein,

Problem gelöst,

läuft. Da muss man sich ja nicht mal weiter drum kümmern.

Das ist halt echt cool. Das bin ich auch

tatsächlich, dadurch, dass wir intern

GitLab nutzen,

weiß ich gar nicht genau, wie das funktioniert. Das ist so

ein Newscast, den man halt im normalen

Geschäft vielleicht nie hat. Also was ich auch sehr cool finde, sind diese ganzen,

wenn wir jetzt bei GitHub schon sind,

sind die ganzen GitHub Actions, das habe ich bei GitLab noch nicht

so hinbekommen. Und zwar kann ich ja aus

Code Actions

generieren, zum Beispiel, indem ich Tags in den Code

reinschreibe. Und dann kann ich ja

daraus dann bestimmte Dinge machen. Also ich könnte zum Beispiel

direkt Issues erzeugen aus To-Do's oder aus

Issues hier oder Fix-Me's,

die halt irgendwo im Code drin stehen und habe halt

dann direkt die Issues damit offen und das finde ich halt

sehr nice, weil man halt dann das dann auch schließen

kann, wenn man das richtig konfiguriert

und dann halt quasi gar nicht mehr seinen Code verlassen

muss, um halt einen vernünftigen Issue-Tracker

auch zu haben, wo sind denn die Issues, wo sind denn noch

was zu tun oder halt zu warten, wenn jemand anders

kann halt direkt sehen, oh ja, da ist jetzt noch das Fix-Me

offen, da muss ich jetzt einfach mal kurz gucken, dass ich

dann vielleicht was dazu beitragen kann. Das ist schon

sehr, sehr schön gemacht. Ja, das ist echt

cool.

Ja, wo du Pipelines sprachst, Pipelines sind

eigentlich die Hölle, dass man irgendwie auf

Produktionsumgebung da kommen kann, wenn man eine einigermaßen

komplexe Infrastruktur dann irgendwann da hat

und bauen muss.

Also ich habe da Jammelhölle im Moment

von mehreren Jammelfights, ich glaube

es sind neun, die

über 2000 Zeilen jeweils lang sind,

wo halt dann über irgendwelche Skripte passieren,

die gemixt sind aus

PowerShell und Bash und halt Python

und dann passieren da

komische Dinge und Wurzling,

tolles Version. Ich habe auch Semantic Versioning eingebaut

und ich wollte halt einfach die Version bekommen.

Und da der Punkt, wo ich die Versionsnummer

pinne, meine PyProjekt Hummel war

oder ist, da habe ich mir gedacht, okay, ich

parse die einfach und benutze die weiter.

Dann habe ich meine Version geändert von 0.9.9

auf 0.9.10, weil

es ging immer noch nicht weiter. Und bumm.

Jetzt sind wir eine Pipeline auseinandergeflogen,

weil ich einfach den Regex falsch geparsed hatte.

Aber solche Kleinigkeiten halt, dass halt so was

ist, ja. Das ist halt lustig, aber

solche kleinen Sachen, die führen immer zu,

dass ein Pipeline läuft, die manchmal ziemlich lange

gedauert. Anderthalb Stunden oder länger.

Ja, das

klingt nach einem Problem, ehrlich gesagt.

Ja, das ist nicht lustig.

Man hat halt auch irgendwelche Regeln von außen, die man gar nicht

beeinflussen kann, in denen man sich halten muss.

Ja.

Man muss irgendwelche Türen aufmachen,

da ein Kabel zwischenhängen, dann die Türe so wieder

zumachen, dass nur das Kabel durchpasst und dann

da durchrufen mit so

Flüstertüten und dann am Ende muss man das alles

wieder abhängen. So was, ja.

Ja, ja.

Furchtbar.

Ja, also das ist auch irgendwie, ja, so wirklich gelöst ist das alles noch nicht auch irgendwie.

Ich weiß nicht, ob der Produktionsrelease auch so eine Art Package ist.

Also vielleicht, also das ist halt so, was wir halt zum Beispiel machen müssen ist,

wir haben ja keine richtige Staging-Umgebung oder so.

Das heißt, was wir machen ist, wir müssen quasi einmal Produktionsversionen komplett nachbauen

und dann da ein Update drauf machen.

Weil, wenn wir halt direkt eine neue Version bauen, dann kann es ja sein,

dass das anders ist als Produktionen zu updaten.

und damit uns halt da nichts schief geht, müssen wir halt erstmals nachbauen.

Das dauert halt dann immer doppelt so lange, weil er zweimal neu bauen muss.

Und dann muss er am Ende, weil wir halt Budget und so,

muss er halt die ganze Station-Gegend erstmal wieder abreißen,

bevor er anfängt zu bauen.

Deswegen dauert das halt auch alles immer so lange.

Aber ja, das ist halt vielleicht auch was mit Paketierung zu tun.

Ist das nicht so ganz public in dem Fall, aber...

Also ich glaube, wir hatten es ja vorhin ganz kurz schon angerissen.

Ich glaube, eine Sache, die, wenn man so ein Package baut,

die wirklich so ein bisschen

ja, unterm Radar läuft, weil es halt

irgendwie niemand so gerne macht, ist halt einfach, dass man die Doku

schreibt, also

es gab ja jetzt, glaube ich, letztes oder vorletztes JungleCon

diesen schönen Vortrag, Docs are didn't happen

das war in Kopenhagen, ich glaube das war

vorletztes Mal

das ist einfach, ich habe es halt auch gemerkt, dass

also selbst in meiner eigenen Firma

wo ich ja echt jetzt keine weiten Wege

zu den Leuten habe, ja, wenn ich sage, hey

da ist das drin, nutzt das mal

das ist halt eine Blackbox, ne

dagegen. Also selbst wenn du dann irgendwie

doch mal jemand irgendwie den Code reintraut und da mal rumguckt,

wenn da halt nicht ordentlich dokumentiert

ist, ich meine vielleicht mal irgendwo ein

kurzer Docstring oder so,

ist schon schwierig. Also da wirklich mal

das irgendwie zusammenzuschreiben, das habe ich

tatsächlich auch im letzten Quartal

relativ viel gemacht und habe da mal bei Read the Docs

da so ein bisschen Markdown

mit Zphinx gepublished, also

Zphinx kompliertes Markdown.

Und da geht...

Auch übrigens ein bisschen nervig mit RestructureTest, geht das

immer besser? Ja, ich

Ich komme mit dem Dokumentformat irgendwie nicht.

Nein, das ist schlecht, aber Sphinx macht das halt sehr ungern mit Markdown.

Ich weiß, ich habe da mehrere, ich habe da so ein paar Adapter.

Man kann das halt ineinander konvertieren, genau.

Ich habe so ein paar Adapter eingebaut.

Musste ich auch ein bisschen googeln, aber inzwischen geht das jetzt ganz gut.

Das bin ich ganz happy damit.

Der war zwischen mich kaputt, der Adapter, ja.

Ja, genau.

Nein, aber das ist tatsächlich, da ist sehr, sehr viel, also dieses Dokumentieren

und auch wenn man vielleicht nicht nur einfach sagt, dass es die Methode und die gibt,

sondern wenn man vielleicht auch so ein bisschen den Kontext herstellen möchte,

so eine Art How-to, das wäre wahrscheinlich eher ein How-to,

wie du vorhin bei deiner, bei dem,

also dass du sagst, hey, guck mal, ich habe diesen Use-Case, ich möchte

mir Daten anonymiasieren, habe ich hier irgendwie einen Rapper, der hilft

dir, oder wenn du irgendwie E-Mails testen möchtest,

da habe ich hier eine fancy Klasse oder ein Mix-In,

das hilft dir, dass man die Leute

auch ein bisschen abholt und erklärt, warum

willst du das überhaupt nutzen, also welches

Problem löse ich für dich? Wenn du dann

nur sagst, so sieht der Code aus, dann

hilft den Leuten das halt nicht. Wo ich das am liebsten mache

und wie es irgendwie am besten auch funktioniert, dass das dann

nicht nur aus meinem Kopf kommt, ist, wenn man das halt tatsächlich

im Art-Pair-Programming macht, wenn man halt dann gemeinsam mit seinem Team oder mit anderen Leuten drauf guckt

und denen das quasi erklärt, was man da gebaut hat oder warum man das gebaut hat, weil dann fallen einem

erstens so die ganzen Bugs auf, die man sonst übersieht, wenn man da irgendwie immer nur selber

mit seinen eigenen vier Augen drauf schaut. Und dann halt

am Ende, wenn man das den Leuten halt erklärt, kann man halt direkt das dann als Docstring dann auch so reinschreiben,

was das dann halt macht. Das macht meistens relativ viel Sinn. Und man merkt halt, dass nochmal der Name, den man da

verwendet hat, irgendwie Quatsch ist. Und das macht man dann noch ein bisschen hübscher. Und dann so kommt man auf eine relativ gute

Qualität, glaube ich. Das ist aber dann wirklich essentiell, dass man mit anderen Leuten das gemeinsam

macht. Das ist auf jeden Fall eine gute Idee.

Aber dann ist auch die Dokumentation in Ordnung. Also was ich

bei Dokumentation oft merke, das finde ich sehr nervig, da habe ich auch noch keine Lösung für gefunden,

die ist halt irgendwie hyperschnell veraltet. Das heißt, wenn ich mir irgendwie Mühe gebe, dass ich so detailliert

aufschreibe, was denn da irgendwie gemacht werden muss, damit das dann läuft, dann muss ich dann

ein oder zwei Wochen da nochmal Zeit reinstecken. Wenn ich nicht jeden Tag irgendwie dann zehn Minuten

wieder die Doku anpasse, die ist halt dann nach diesen zwei Wochen

einfach nicht mehr benutzbar.

So, das ist irgendwie ein bisschen blöd.

Und das führt halt auch dann dazu, dass man nicht

so Lust hat, dann das immer zu

machen ordentlich, weil... Also da hatte ja

der Kalten Gibson jetzt bei dieser

DjangoCon einen Vortrag bezüglich

wie dieses Static Dynamic Websites,

Static Dynamic Pages

hieß es, glaube ich. Ja, mit einem Zwings und...

Genau, ich habe vergessen, wie das Package heißt, das er gebaut hat.

Müsste man mal nachschauen.

Benutzt das dann einfach doch Zwings irgendwie?

Also die Idee dahinter ist, dass du quasi

über Django Markdown,

also du schreibst Markdown

und das wird dann als Django HTML

Template gerendert, rausgerendert.

Und da... Hast du das nicht auch die Django Docs,

die Dokumentation, die tatsächlich in diesem Format

irgendwie selber ist? Möglich, möglich.

Auf jeden Fall, der hat das da halt ein Package draus gemacht

und das ist halt, also ich glaube

ein Problem, das man damit lösen kann, ist halt

genau, also jetzt nicht Docstrings, weil die musst

du halt, die sind eh im Code, aber wenn du halt

diese, zum Beispiel so eine How-to-Dokumentation,

bei mir läuft das halt irgendwie,

ja, es ist halt schon irgendwie im Code drin, aber

ist auch jetzt irgendwie separat gehostet und

wenn du jetzt, bei Pactis ist es eh schwierig,

weil die laufen ja nirgendwo, wenn du zum Beispiel

sagst, ich möchte jetzt irgendwie Dokumentation für

meine eigene Seite, also zum Beispiel ich möchte irgendwie

die Business-Logik und die Technik und irgendwie sehr

detailliert das aufschreiben, muss ich vielleicht auch, wenn es irgendwelche

Compliance-Sachen gibt.

Wie hingehen das nochmal mit dem Backup oder so, ja. Genau,

dass du die Sachen dann einfach direkt im Code,

im gleichen Repo, im gleichen Commit machen kannst und

dann zum Beispiel auch einfach da ein

Linting reinbauen kannst, sagst du, Moment mal, du hast da was angefasst,

du hast das

Markdown nicht dazu angepasst.

Das sind, glaube ich, sehr, sehr coole Use Cases.

Dafür, wenn man da halt wirklich, wenn das wirklich

wichtig ist, also du hast

halt dann die Nähe von Dokumentation,

die sich eigentlich weit weg anfühlt, das ist irgendwo

ein Marktanteil, die irgendwo umliegt und die irgendwo gehostet

ist, dass du dann wirklich ins Projekt

reinbringst. Ich habe es noch nicht ausprobiert

tatsächlich, aber ich könnte mir vorstellen, dass das

genau für solche Use Cases, also für sehr große

Projekte, wo man das machen muss,

das vielleicht so ein bisschen dann

näher bringt und damit auch die Motivation erhöht,

dass man es da wirklich tut. Also ich war ja echt Fan

auch von diesen autogenerierten Swing Stocks,

Autodoc aus den Docs-Sinks heraus und so,

dass du einen halt so ein bisschen dazu zwingst, den Docs-Sinks aktuell

zu halten. Aber noch besser sieht das

tatsächlich, jetzt muss ich noch kurz für Jochen und Lasse

brennen, dieses NBDEV aus, weil man in Notebooks

halt das Markdown auch direkt mit

reinschreiben kann, wenn das ordentlich aussieht.

Mein Notebook hat was, was ordentlich aussieht,

ja, und was dann automatisch dann

zur Dokumentation von diesem Code führt, das dann

irgendwie aus einem Guss hat. Das ist schon irgendwie

sehr charmant für bestimmte Sachen.

Ja, gerade wenn man, glaube ich, so Pakete

neu entwickelt, irgendwie das dann hinterher nochmal

angucken will, das ist schon schön.

Ja, ich sage mal

gerade bei Data Science

Geschichten ist es besonders schön, weil

das halt, zum Beispiel man hat

ja oft dann irgendwelche Visualisierungen

Visualisierung ist natürlich besonders

Das hast du ja sonst eigentlich, weiß ich nicht, wenn du jetzt irgendwie ein Django-Paket

hast oder so, hast du das im Grunde kaum

Insofern ist es da nicht so schlimm, wenn man das halt

im Notebook hat und auch

wenn du bei so Data Science Geschichten, wenn jemand

eine Visualisierung verbessern möchte, dann

kannst du halt da in einem Pull-Request direkt

den Unterschied in der Visualisierung sehen

und direkt im Notebook und musst halt nicht

erst das Paket bauen,

also den Pull-Request dann bauen,

angucken, dann die Visualisierung anzeigen,

erstmal bis dahin kommen. So was ist halt direkt da.

Dafür ist es halt total super.

Wenn man das jetzt gar nicht braucht, dann

hilft es einem nicht so sehr,

auch wenn es sonst auch ganz nett ist.

Ich habe jetzt gerade nochmal geguckt, ich glaube das Paket ist

Django Sphinx View

von Carlton Gibson.

Ja, ich finde das auch

auch total interessant. Es gibt ja so diverse Ansätze.

Den kannte ich jetzt auch noch gar nicht mehr, war das

auch überhaupt nicht klar, dass die Django-Dokumentation

das so macht, dass das halt irgendwie

nur

JSON ist, was im Grunde aus Sphinx rausfällt

und dann man halt noch dynamische

Geschichten mit dazu machen kann.

Aber das ist auf jeden Fall

auch eine sehr interessante Geschichte. Markdown, dann den

Mistparser, dann das Ganze

in Restructured Text, das Ganze

dann wieder dynamisch vielleicht serven,

ist sehr interessant.

MBDev finde ich interessant

ich finde voll interessant, was in dieser

Vue.js, Vue.js mache ich auch so ein bisschen

versuche ich auch reinzukommen, was die da machen

die nehmen ja VuePress

beziehungsweise VitePress jetzt

genau, das ist auch total

toll, das sieht super aus

bitte?

excuse me, Vite

das ist auch so blöd, wenn man dann

irgendwie, da habe ich auf irgendeinem

Vue Meetup

einen Vortrag über VitePress

gehalten und dann

mit der White Press gesagt oder sowas

und dann kam die erste Frage und jemand sagte dann Viet Ich habe es gerade gestern halbe Stunde lang jedes Mal falsch gesagt Aber genau so ist das halt

Und das ist aber auch

voll toll, weil was

daran super ist, ist, dass man direkt sieht,

wenn man was an der Dokumentation ändert oder so,

das ist halt sofort alles live.

Mit Sphinx und so, das ist ja dann doch eher so,

man muss das erstmal dann irgendwie bauen.

Das dauert alles ein bisschen, bis dann auf einer Webseite ist,

das dauert nochmal.

Während bei VitePress oder so, das ist halt sofort da.

und man editiert es quasi live.

Aber

so das rundum

sorglos Ding für alles gibt es irgendwie nicht.

Es gibt so diverse, sehr interessante

Geschichten, die so in Teil-Communities

irgendwie so

entwickelt worden sind.

Also ich würde auch fast sagen,

Beatpress irgendwie,

das ist schon nett für Markdown-Sachen,

Markdown-Sachen hosten oder hochladen, aber das

generiert halt immer noch nicht seinen Content.

Den muss man halt immer noch selber schreiben.

Aber man kriegt ihn damit

sehr gut aussehen.

Die Vue-Dokumentation ist ja

VuePress, weil das kann halt auch mal ein bisschen mehr.

Und das ist eigentlich, das ist auch

alles Markdown, mehr oder weniger.

Das sieht schon sehr schick aus, muss man sagen.

Gerade auch im Vergleich

zu Django-Dokumentationen. Django-Dokumentationen ist jetzt

deutlich mehr und deutlich umfangreicher und vollständiger.

Aber

die Vue-Dokumentation sieht schon besser aus.

Und

das sind ja auch so kleine Animationen

und diese ganzen Geschichten, die halt bei Vue so drin sind.

Ja, also relativ einfach, dass

alles mit direkt auch als Paket kommt.

Dann funktioniert das einfach.

Das ist sowieso ein bisschen das Problem

von Dango-Sachen, dass das immer so sehr

statische Seiten sind immer.

Ja, aber nicht unbedingt.

Also wenn man das halt hätte, das macht man

zum Beispiel wieder nicht, aber das ist halt dann

unheimlich der Overhead, das dann halt in die Projekte dann alles

mal reinzubringen und man muss halt eigentlich an mehreren Stellen

gleichzeitig die Sachen bauen und das

wird dann alles so ein bisschen, man verliert halt Features,

die man vielleicht möchte oder so, das ist

alles noch nicht so. Ja, man hat halt

immer Entscheidungen zu treffen, für welchen Case man was lieben möchte.

Das ist allerdings wahr.

Ja, Pakete. Hast du noch was, Ronny?

Also tatsächlich, ich habe bis noch so zwei, drei Kleinigkeiten,

die mir jetzt aufgefallen sind, als ich da, wie gesagt,

jetzt so ein bisschen Streamlining gemacht habe bei dem Package.

Das eine ist, ich habe angefangen, bei allem, was ich anfasse,

jetzt nochmal Type Hinting zu nutzen.

Es ist ja so, mit der Konto, wer es diskutiert hat,

ob es gut oder schlecht ist.

Also ganz radikal, jedes Argument in jeder einzelnen

Methode. Ja, also es ist

immer ein bisschen schwierig, wenn du halt

Klassen hast, die aus einem eigenen Scope

kommen, weil du halt dann super schnell in den Circular Imports rennst.

Da ist es dann so, dass ich zum Beispiel sage,

okay, wenn ich jetzt, keine Ahnung, ein User

Query Set habe, dass ich dann nicht sage, das gibt ein User

Query Set zurück, sondern es gibt einfach nur Query Set

zurück. Also das abstrakte Django-Ding.

Aber ich finde das halt super

praktisch, also vor allem...

Was ist falsch?

Also wenn du halt eine...

Ja, ist halt der Vater.

Also es ist ja so ein Typ Curricet

Ja, weißt du, ja, na, ist dann nur die Base

Ja, aber das ist schon, glaube ich,

auch, wie man das

man sollte halt irgendwie die Abstraktion

von der halt abhängen und die dann halt auch

Also im Endeffekt, wenn ich halt nix zurückgebe

also nicht halbhinter, dann weiß jemand nix

Wenn ich weiß, da kommt ein Curricet zurück, dann weiß ich

immerhin schon mal Edits keine Liste

Ja, aber okay, aber das ist schon besser

Also man macht das ja in sowas wie TypeScript

oder sowas so relativ detailliert, dass man

irgendwelche Interfaces dann dafür baut, ne

und die dann halt dann die Typen exenten, die man

aber auch verwenden muss, weil ansonsten ist das ja falsch.

Also wenn du jetzt ein User-Query-Set hast, weil vielleicht

hast du ein Custom-Query-Set, wo du irgendwas

Besonderes dran gemacht hast, irgendeine Methode, die

andere Query-Sets nicht können oder so.

Und wenn du dann halt sagst, das ist nur ein Query-Set und dann

kommt da irgendeine Methode, die Query-Sets gar nicht können,

das wäre irgendwie seltsam dann. Und das müsste eigentlich

auch gelintet werden, finde ich.

Also du hast recht, es ist nicht ganz trennscharf.

Dadurch, dass ich das Problem mit den Circular-Imports

noch nicht gelöst habe und ich auch gar nicht weiß,

ob es eine Lösung gibt,

habe ich mich jetzt einfach dafür entschieden, ich gebe

dem Nutzer halt einfach

einen Ticken mehr

Informationen mit.

Eine Verantwortung.

Meistens finde ich es eh, also sehr sinnvoll ist es

vor allem eh bei trivialen Datentypen,

weil du halt dann, ob das jetzt irgendwie Decimal oder Float

oder ein Integer oder sowas ist, das macht ja schon

schnell irgendwie die Berechnung kaputt.

Aber ich finde das

tatsächlich praktisch, wenn du vor allem, wenn man so Helper-Methoden

oder irgendwie Sachen hat, also wo

andere dann meinen Code nutzen,

das ist ja total praktisch, dass dir dann direkt die

Ideen anzeigt, so sorry, da stimmt irgendwas.

Genau, das ist, finde ich, auch das Wichtigste an diesen Type-Links in Python,

dass du halt tatsächlich, wenn du den Lint richtig konfiguriert hast,