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, 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
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.
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,
während dem Schreiben siehst,
findest du da irgendeinen Arch-Boss und das ist wirklich praktisch.
Aber ich benutze es auch tatsächlich meistens nur für
komplexe Dinge, also wo es fraglich ist
oder wo du noch nicht genau weißt, was es ist. Dann sage ich halt direkt,
das ist jetzt explizit und die anderen Sachen, die gehen halt einfach so durch.
Also tatsächlich
auf der
PyCologne, das ist ein Python-Meetup
in Köln, das monatlich stattfindet,
da hatte
der Organisator mal irgendwann gesagt,
dass er inzwischen jetzt übergegangen ist,
dass er quasi in jeder Funktion, die er schreibt, das erzwingt, dass man die Keyword-Arguments nimmt.
Das geht ganz einfach, indem man zum Beispiel aus einer Methode, das ist dann irgendwie von einer Klasse,
da ist dann nur der erste Typ ist immer, nicht Typ, die erste Variable ist immer self.
Dann machst du Komma, Sternchen, Komma und danach deine anderen.
Und dieses Sternchen sagst du ihm quasi, es kommt hier quasi kein normales Argument.
Dahinter kommen die Keyword-Argument.
Das heißt, es ist verboten, dass du sagst, ich gebe den ersten Parameter normal rein.
Habt ihr verstanden, was ich meine?
Ja, also kein normales Argument gibt so ein Keyword-Argument.
Genau. Und das finde ich jetzt, also bei manchen Sachen ist es natürlich Unsinn.
Ich meine, wenn du eine Sache hast und das auch klar ist, aber insbesondere bei so Methoden
oder wenn man mal irgendwie dann doch mal so vor so einer Funktion steht,
wo dann irgendwie doch mal so drei, vier, fünf Sachen reingehen,
was ja irgendwie auch so ein bisschen unlesbar ist,
da den User zu erzwingen, vor allem wenn da mal einer hinkommt
und das irgendwie ein bisschen refactoren möchte,
dann ist er auf jeden Fall sichergestellt, dass niemand aus Versehen,
also zum Beispiel wenn man die Reihenfolge tauscht und man möchte irgendwas da vorne rein,
dann kann man das einfach machen, weil es ist der Keyword-Argument
Aber das schluckt ja nicht das
mit dem ständigen Rest einfach weg dann? Ich überlege gerade, wo
der dann rausfällt
Also der
Argument wird ja wegschlucken, die würden einfach nicht mehr
auftauchen, aber die werden halt nicht in den Keywords dann gemappt
Nee, der macht dann tatsächlich einen Fehler
Der wirft bei ganz, das darfst du nicht
Also das ist sehr praktisch, weil ansonsten, das wäre ja blöd
wenn das passiert, was du sagst. Tatsächlich sagt ihr dann
Sorry, da müssen Keyword-Arguments drin sein
Und das
finde ich, wie gesagt, es gibt Methoden, da macht das keinen Sinn
Aber wenn das irgendwas
sehr, sehr wichtig ist oder sehr, sehr ähnliche
Variablen reinkommen. Dass man zum Beispiel,
weiß ich nicht, du hast irgendwie User 1 und User 2 oder sowas,
die irgendwie eine andere Semantik haben,
aber halt vom gleichen Typ sind und das
einfach dann dir trotzdem zu Ende rechnen würde, was du da tust.
Da finde ich das echt nett, wenn man das
macht. Einfach, weil
du halt dem
weiteren User, ob das du bist oder
jemand anders, mehr Semantik erzwingst.
Ja, also
exklusiv nur Keyword-Arguments erlaubt.
Gibt es nicht doch irgendwie ein Parameter für, ich habe da irgendwie
Es gibt da irgendwas mit dem Slash, ich weiß es nicht mehr genau.
Aber ich weiß es jetzt auch nicht mehr genau.
Es gibt also Position-Only-Arguments, es gibt
auch Keyword-Only-Arguments mit dem Stern.
Ja, aber genau.
Also ich würde
jetzt sagen, wenn man viele Argumente hat,
dann ist erstmal, also ich würde sagen,
naja, es gibt schon mal Fälle, wo das gut ist,
oder wo man das halt einfach braucht,
aber wenn es jetzt so deutlich mehr als drei
werden, dann denke ich mir schon so, okay, kann man das
nicht vielleicht irgendwie anders machen, weil das kann sich
ja eh keiner merken. Also ich meine, wenn die
Idee das vervollständigt, okay, dann geht es vielleicht, aber
ansonsten...
Wenn man ja immer durchpipen muss durch irgendwie mehrere Ebenen.
Was ich dann oft sehe, ist halt
irgendwie, oder wo ich denke,
da macht es dann nicht mehr so viel Sinn, ist halt, du hast
eine Riesenliste, wo dann Leute dann anfangen,
okay, Funktion geht auf, Klammer auf
und dann kommt dann halt irgendwie so
eine Riesenliste von Zeug, ja, dann
Klammer zu und dann kommen erstmal 100 Zeilen
Überprüfung, was man denn da bekommen hat
und Fehlerbehandlung, wenn
das irgendwie nicht so richtig zusammenpasst und so
und ich denke so, ja, okay,
Das kann man bestimmt in die besser machen.
Ja, aber
ja, es ist schon
interessant, ja, überhaupt diese ganze
Teilpainting-Geschichte oder so, da bin ich auch noch nicht so richtig
Ich mag es natürlich, wenn die
IDE mir hilft und irgendwie Dinge vorschlägt
oder unterkringelt, wo ich einen Fehler gemacht habe.
Kann Wim das auch?
Gutes Linting?
Ich weiß es gar nicht.
Ich habe das nie wirklich verwendet, glaube ich.
Also irgendwer aus dem Offline bestimmt ja.
Bestimmt, ja. Ich habe das jetzt aber gar nicht
darin verwendet bisher.
Ja, ich habe das auch selber, benutze ich das
fast nie, weil ich würde sagen,
es macht ja eigentlich auch, also wäre jetzt mein
Bauchgefühl nur dann Sinn, wenn man Pakete
schreibt, die dann halt irgendwie von anderen Leuten verwendet
werden und das mache ich eigentlich auch nicht so richtig
häufig. Daher,
ja, ich habe das, aber müssen wir mal eine Sendung
zu machen und muss ich mich damit beschäftigen, das wollte ich
auch schon immer mal tun. Das ist wirklich ein guter Grund, das mal zu
machen, ja.
Ja, und sonst, was ich auch ganz praktisch
finde, wie gesagt, man kann halt über diese
über die Package-Metadaten
kann man halt super viele praktische Sachen
mitgeben und da die PyPy-Seite halt wirklich
die gibt da unendlich viel vor und
viele Packages, die man so sieht, die nutzen das alles gar nicht,
was sehr schade ist. Also nicht nur, dass du halt dann
direkt an vorgegebener Stelle den Bug-Tracker,
das Repo, den Maintainer,
keine Ahnung was mitgeben kannst, du kannst halt auch
diese Badges nehmen, wo du dann zum Beispiel
sagst, hey, hier, das ist die aktuelle PyPy-Version
oder der Bild läuft durch oder meine Docs funktionieren
und es gibt ganz unendlich viele Sachen,
unendlich viele Tools, die man da einfach anbinden
kann und damit kann man halt,
wenn man halt mal ein Package macht und auch gerne möchte, dass Leute
das nutzen, kann man halt sehr viel
ja, ist einfach
auf die Seite. Du hast ein bisschen Convenience
dazu. Genau, Convenience und auch die Leute
einfach so ein bisschen so, hey, guck mal, ich weiß, was ich hier tue,
ich habe hier irgendwie an alles gedacht. Auch bei
diesen, da gibt es auch so Metadaten, wo du zum Beispiel sagen kannst,
in welchem Status befindet sich das?
Ist das gerade eine Alpha, ist das eine Beta, ist das
Production-ready so? Da kannst du
genau auflisten, welche Dependencies,
was ich vorhin schon meinte, bei der Matrix,
die und die Python-Version unterstütze ich, die und die Django-Version
unterstütze ich. Ist halt super praktisch, wenn halt
jemand kommt, der einfach gerade ein bisschen browset bei Python
und einfach sucht, okay, ich möchte mein Problem lösen,
welches Package geht denn für mich? Ich habe vielleicht
eine Nebenbedingung, weiß ich nicht, ich bin noch auf Django 2 oder
sowas und kann nicht so ohne weiteres hochgehen
und dann einfach siehst, ach cool, dann zerstützt das,
steht da, da muss man nicht irgendwie sich lange durch Dokus
durchgraben oder weiß der Geier,
aber es ist einfach super convenient und
da gibt es sehr viel, ich mache das tatsächlich immer so,
dass wenn ich irgendein Package gefunden habe,
dass das sehr ausführlich nutzt, dann gucke ich mir GitHub
an und klau dann da die Sachen
und schaue es mir ab,
was man alles machen kann.
Also ein gut geklautes Hype gewonnen.
Ja, auf jeden Fall.
Das wollte ich eben noch sagen, das habe ich dann
vergessen.
Inzwischen mache ich das auch meistens so,
dass ich dann halt die Tests in einem Verzeichnis habe
und das kommt halt nicht mit ins Paket.
Ich lese mir oft,
wenn ich jetzt wirklich verstehen will,
was irgendwie Software macht,
dann fange ich oft mit den Tests an, mir die anzugucken.
Aber da mache ich sowieso einen Checkout von dem
Repository, dass ich dann
in das Paket selber reingucke.
eigentlich auch nicht.
Insofern, genau, ich mache das inzwischen
auch so, dass die Tests halt nicht mehr in dem Paket mit drin sind.
Ja.
Ja, man kann schöne Sachen im Paket machen.
Auf jeden Fall. Habt ihr noch was?
Ja, also ein großer Teil, den wir jetzt
nicht haben, aber vielleicht machen wir den dann auch mal irgendwann anders,
weil es jetzt auch gar nicht so,
das betrifft ja auch eher wieder so den Data Science
Teil
Conda, das ist natürlich auch wieder eigene
Pakete. Im Grunde auch
ein eigener Teil wäre halt sowas wie
bau ich ein Binary, einfach
ein Executable-Ding irgendwie bauen kann.
Das
hätte man jetzt auch hier noch machen können,
aber ich bin nicht vorbereitet.
Keine Ahnung.
Ich muss das Ganze nochmal angucken, wie das so funktioniert.
Ich habe gerade benutzt, Leute. Also ich bin kein Fan davon
persönlich, aber
es nimmt sehr viel Kontrolle, die ich nicht
abgeben möchte, immer ab. Das muss man immer so
im Zaum halten.
Ach so. Wieso?
relativ intrusiv. Das heißt, man kann es nicht einfach so
daneben in den Rest packen.
Also ich muss zum Beispiel, um es mit PyEnv
zu benutzen, als PyEnv zu funktionieren,
mal so ein bisschen rumhacken, dass das vernünftig geht.
Ja, manchmal funktioniert es halt
auch nicht mehr richtig, das stimmt schon.
Oder es macht halt irgendwelche Pfade kaputt oder
schreibt sich in irgendwelche Systemkonflikte rein,
wo es eigentlich gar nichts zu suchen hat, wo man es dann wieder rauslöschen
muss und so. Ja, anstrengend.
Genau,
aber ist auf jeden Fall auch noch eine interessante
Geschichte. Ja, ansonsten
und
ne, war's nicht.
Fällt mir jetzt auch nichts mehr ein.
Ja.
Ja, ich glaube, eine Sache, die ist noch ganz cool,
also ich habe tatsächlich gemerkt, dass
selbst wenn ich, also wenn ich Code schreibe, dann bemühe
ich mich dann ja auch, dass der ordentlich ist, dass der getestet ist
und so weiter, aber sobald man dann anfängt,
den in Package zu legen, fallen einem sofort noch
10 Use Cases ein, die man eigentlich noch mit abdecken
sollte und die Codequalität
ist auf jeden Fall nachher immer nochmal 20-30%
besser gefühlt, wenn ich das wirklich Package-Ready
gemacht habe. Einfach, weil man dann
und denkt, ach komm, du hast so ein Spezial
für dein Projekt, ja, das weiß ich nicht,
du hast so ein separates User-Model,
das lasse ich einfach so nachdenken.
Nee, das funktioniert nicht so. Das muss man nochmal sauberziehen
und geradeziehen. Also das kann
tatsächlich sehr, sehr pädagogisch wertvoll sein,
einfach die Sachen mal
zu versuchen auszulagern,
weil man irgendwas Cooles gebaut hat.
Ja, auf jeden Fall.
Ja, wollen wir
noch Pics machen?
Habt ihr Pics der Woche?
Ja, okay.
Dann fange ich direkt an. Allerdings ist es kein Paket oder Software, sondern es ist ein Artikel, ist aber auch lang.
Viel Spaß mit. Auch von Hinex Subclassing in Python Redux.
Ich weiß nicht, ob wir den jetzt irgendwie...
Den kannst du nochmal wiederholen, bitte.
Subclassing in Python Redux.
Ja.
am 22. Juni rausgekommen.
Das ist jetzt, also gefühlt noch gar nicht so lange her,
vielleicht eine Woche oder, ja, müsste eigentlich
etwas mehr als eine Woche vielleicht sogar.
Ja, ich glaube eine Woche, zwei Tage, Jochen.
Kann sein. Ist auf jeden Fall sehr interessant,
genau, schöner, langer Artikel,
wo er irgendwie so seine Erfahrungen über die
letzten paar Jahre viel beschreibt
und was alles nicht funktioniert. Er verlinkt auch
viele sehr interessante Quellen.
Und genau, das ist so,
die Erfahrung habe ich auf jeden Fall auch schon gemacht,
dass wenn man Interfaces so,
auch wenn man Libraries schreibt, so definiert, dass sie darauf basieren, dass man dann irgendwie von den Sachen erbt, die man da geschrieben hat, dann hat man so am Anfang das Gefühl, das ist voll gut und dann irgendwann denkt man sich, oh mein Gott, was habe ich getan? Das ist schrecklich. Ich komme da nicht wieder raus.
Und ja,
beschreibt er, also das ist
auf jeden Fall,
die Zeit nehmen wir mal so einen langen, dunklen Nachmittag.
Jetzt ist gerade Sommer.
Zeit hat, dich das mal durchlesen
und da ist viel lehrreiches
Zeug drin. Sehr, sehr gut.
Guter Artikel.
Okay, interessant.
Ronny, hast du auch einen
Pick der Woche? Ein Modul, das du
wahrscheinlich möchtest?
Ich glaube tatsächlich
gerade nicht aus dem FF.
Oder irgendein Talk oder irgendwas
Interessantes?
Ja gut, ich meine, Dominik hat es ja
gerade schon irgendwie fünfmal angesprochen, dieser erste
Talk von der DjangoCon mit dem
Programming for Pleasure.
Ach ja, okay.
Ich meine, das war so schön heretisch.
Das hat auf jeden Fall
sehr, sehr viel Spaß gemacht, den zu hören.
Ich glaube,
der Talk ist so meta, den kann man sich auch gut anhören,
wenn man selbst nicht so tief
im Coding drin ist.
Das wäre vielleicht auch nochmal ganz interessant.
Es passt jetzt zwar nicht so richtig da rein, aber wie war denn
die DjangoCon, wie ist das eigentlich
aus Sicht,
ihr wart ja irgendwie Sponsor,
als Firma, wie war das
eigentlich sozusagen aus dem
Blickwinkel?
Ja, es ist schon, also wir haben uns alle
immer, also wir haben mit ein paar wenigen
Leuten im Büro geguckt, also
ein paar Leute haben von zu Hause geschaut, ein paar wenige Leute waren im Büro
und Corona und so ist ja alles nicht so einfach
und haben uns natürlich
alle immer schon gefreut, wenn dann unser nagelneues
Promo-Video dann da über ein Bildschirm
gelaufen ist
und ja, ist auf jeden Fall auch
cool, also irgendwie da das mit zu unterstützen,
da irgendwie ein bisschen
was zurückgeben zu können, weil ich meine,
wir nutzen ja schon Dango irgendwie sehr, sehr viel
und
ja, ansonsten,
man kriegt da halt so ein paar Möglichkeiten,
du kannst dann irgendwie einen Job auf
einem Slack posten, du kriegst einen Kanal,
den du dann bearbeiten kannst, das haben wir tatsächlich
gar nicht so wirklich gemacht,
weil
ja,
wir hatten da irgendwie
gar nicht so drüber nachgedacht, sage ich mal.
Also, weil es war immer so, ja klar, wir sind im Slack
und dann schreibst du mit den Leuten und
ein paar Leute haben sich noch gefragt wegen den Bewerbungen,
wie es denn damit aussieht und wie es denn ist
mit, wenn man halt
irgendwie kein Deutsch kann und mit Remote und alles mögliche.
Aber da haben halt
manche Firmen, haben da halt dann richtig Party gemacht
in ihrem Kanal und richtig dann da
den Kanal bearbeitet und
ist eigentlich auch ganz cool, weil das da so ein bisschen
ein anderes Element dazu gibt, weil das ja
es ist irgendwie,
also ich weiß gar nicht, wer das war,
und das ist schon ganz cool, weil das ist irgendwie auch eine ganz coole App,
mit den Leuten so auch jetzt als Firma
zu interagieren, ohne dass man jetzt irgendwie so direkt mit der
Mega-Werbe-Call oder sowas kommt und so
hey, ich will euch was verkaufen.
Von daher denke ich mal, also wir haben
und Jochen unterhalten sich über die Programmiersprache Python
Ich tippe mal, dass dieses Hybrid-Ding
wird auch einfach bleiben.
Ja, vor allem, ich meine,
es waren glaube ich 700 Leute
oder so im Slack, habe ich gesehen.
Normalerweise sind Django-Cons auf 300 irgendwas begrenzt
oder 400 oder so. Super für Leute, die halt gerne
irgendwie quasi denen das Geld geben möchten
und gerne dabei sein möchten, aber eh nicht können,
weil die halt irgendwo ganz weit weg wohnen
oder keine Kohle haben oder keinen Urlaub kriegen oder so.
Und die Leute einfach mitzunehmen
und trotzdem teilhaben zu lassen,
ist halt schon cool.
Ja, stimmt.
lassen. Manchmal ist es weniger Commitment,
es ist mehr so Leaching
und es gibt natürlich auch die Ausnahmen
mit Leuten, die eigentlich gerne was machen
würden, aber sich nicht trauen rauszugehen. Das ist halt
immer so schwierig.
An welcher Seite setzt du da
jetzt an? Ich habe noch nicht so
rausgefunden, was denn da die ideale
Hybridform von ist, wie man das machen kann,
ob es verschiedene Sachen dazu geben muss. Aber ich glaube also
jetzt bei der Jungle-Community, glaube ich, gibt es so viele Leute,
die da wirklich Spaß dran haben. Die Tickets sind ja auch eigentlich immer
ausverkauft, also die For-Or-Tickets. Da muss man
sich, glaube ich, keine Sorgen machen, dass man sich da selbst kannibalisiert.
also das kann ich mir jetzt nicht vorstellen
ich meine beim DagoMeter
jetzt
werden wir auch, ich meine es ist frei so wie es mit Corona
und so weiter geht, aber ist es auch
der Plan, dass wir jetzt vielleicht beim übernächsten Mal
auch wieder das im Büro machen
am nächsten Mal müssen wir mal schauen, wie das so klappt
aber dass man auch sagt
komm, wir stellen auf jeden Fall einfach eine Cam
auf und wenn jemand Lust hat, sich irgendwie
remote zuzuschalten, dann machen wir das halt
ich weiß noch nicht, ob das gut funktioniert, ob das irgendwie doof ist
ob dann vielleicht alle Leute eh sagen, boah geil
vor Ort Bier trinken
mit Leuten reden,
socialisen.
Das ist viel besser, das braucht man gar nicht.
Aber ich glaube, die Möglichkeit würde ich jetzt einfach schon
anbieten, weil wie gesagt, für manche Leute, die dann halt
irgendwo von weiter weg kommen oder
wenn jemand in der Eifel oder sowas,
also jetzt hier, Kölner Raum, Eifel ist ja
irgendwie so.
Ist dann halt teilweise vor allem
abends schwierig, hin und zurück zu kommen, wenn du nicht
extra ein Auto fährst oder so.
Und einfach die Leute noch mitzunehmen,
wenn die da Spaß dran haben, das fände ich
schon gut, das möglich zu machen. Wie gesagt,
und hat gesagt, wir müssen mal gucken, welchen Modus wir nachher dann tatsächlich fahren,
aber ich tippe mal, dass wir wahrscheinlich auf Hybrid gehen.
Du warst auch in Berlin beim Django Meter Pass, wird sich.
Ja, genau. Ich bin vom Philipp, der ist jetzt seit Januar der Organisator davon,
angeschrieben worden über LinkedIn, habe mich gefunden und hatte mich nach ein bisschen Austausch gefragt
und haben uns direkt sehr gut verstanden.
Und dann habe ich einen Gastvortrag gemacht
und habe ein
kleines, persönliches, very strongly
opinionated Best-of der Dungocon
zum Besten gegeben.
Ich dachte, du hättest über Packages geredet, schade.
Nein.
Und einfach quasi kurz erzählt, was die Talks sind
und einfach den Leuten
einfach so, hey, wenn du dich für dieses Thema interessierst,
dann kann dieser Vortrag für dich interessant sein.
Vorträge, die so ein bisschen mir vorbeigegangen
sind, habe ich dann auch relativ offen
gesagt, dass das bei mir persönlich vorbeigegangen ist, aber
und mir ging es auch gar nicht darum, zu sagen,
irgendwer ist doof oder so, sondern das waren wirklich so meine Eindrücke,
die ich quasi beim
davor sitzen, acht Stunden am Tag
mir aufgenommen habe
und einfach dann so, ja,
keine Ahnung, also zum Beispiel gab es einen Talk
über diese Interactive Shells, das ist
einfach nicht meine Welt gewesen. Ich habe
noch nie andersweise
mit diesen Sachen arbeiten müssen und
mehr als irgendwie mal mit der Django Shell
mal kurz ein Model irgendwie aus der Datenbank gucken, habe ich halt noch
nicht gemacht, so ungefähr, ja. Und dann
irgendwie zu sagen, ich will da irgendwie Betriebssystem drauf installieren
oder sowas. Es war
einfach sehr weit weg. Das nicht heißt, dass
der Talk schlecht war oder sowas. Das hat mich halt
der Webentwickler einfach nicht
abgeholt, was ja auch total legitim ist. Es ist ja auch schön,
dass das breiten Wissen ist, aber das ist
im Endeffekt das, was ich dann da
so ein bisschen erzählt habe einfach.
So, hey, wenn ihr euch dafür interessiert,
ist das cool und so, dass man halt dann,
weil wenn man nicht dabei war,
dann trotzdem vielleicht
so ein paar Ideen hat, wenn es dann irgendwann mal auf YouTube kommt.
Ich glaube, die wollten, dass die so nächste Woche mal online
stellen, die Talks. Ich weiß gar nicht, ob die das schon gemacht haben.
einen Monat, das müsste ja genau
dieses Wochenende sein.
Wann war die JungleCon? 2. Juni oder so?
2. bis 6. Juni, ja. Genau, und jetzt haben wir ja
morgen. Ja, morgen ist es weiter.
Genau, mal gucken. Ich werde das auf jeden Fall
dann auch noch in die Show Notes packen, wenn
sich das dann geben soll.
Sehr interessant. Achso, ich habe auch noch
einen Pick der Woche. Und zwar, ich weiß nicht,
ob ihr TLDR kennt.
Das gibt es auch auf PyPy und das ist eigentlich so ein
Shell-Tool. Ihr kennt bestimmt
Linux Command, um sich die
Mainpages anzugucken von einem. Was macht denn das?
und TLDR geht einen bisschen anderen Weg, ist aber sehr, sehr geil.
Also ich stehe im Moment total drauf.
Du kannst einfach das Gleiche machen wie bei Man.
Das heißt, du gibst TLDR, du kommst mal ein
und es zeigt dir nicht die Man-Patches an, sondern
die häufigsten vier oder fünf Use-Cases,
wie man das Ding benutzt.
Ah, okay, das ist super.
Das ist echt geil, weil du siehst halt direkt, wie man das benutzen kann, wenn man das benutzen will
und musst nicht erst mal irgendwie in den Man-Patches gucken,
wie war das und was heißt denn der Parameter.
Nee, du siehst halt direkt irgendwie,
wie ging das jetzt nochmal mit dem Grab oder
mit dem Find und dann weißt du direkt, ah, so benutzt man das.
Ah, total super und
Cool.
Gehe ich auch ein Short auf einer kleinen Seite, das ist auch meistens wirklich nur
passt alles auf eine Seite, kannst du angucken.
Mega geil, kann ich echt empfehlen.
Das habe ich gefunden als Teil über die
modernen Linux-Commands oder sowas.
Kennt ihr das?
Das heißt tatsächlich
Modern Linux,
muss ich kurz gucken, ja genau, Modern Unix, Entschuldigung, nicht Linux,
es gibt ja einen Unterschied,
von Ibrahimdiv und das ist
sehr schön, gibt es die verschiedensten
Erweiterungen.
Genau, das habe ich, genau, Watt, Exa, ja, ja.
Genau, genau, genau. Da ist auch das TLDR dabei.
Und viele tolle Implementierungen
auch in Rust und so, aber das ist
sehr nice, wenn man modernen Linux mag,
UDUX mag.
Ja, das TLDR ist auch auf PyPy tatsächlich und
kann sich einfach nicht schnell ziehen
und macht Spaß.
Ja, sehr cool. Wunderbar. Muss ich mir auch mal angucken.
Vor allem.
Ja, ich glaube, wir sind am Ende für diese Folge.
Vielen Dank, dass du wieder da warst, Ronny.
Vielen Dank für die Einladung.
Hat viel Spaß gemacht.
Ja, und ich würde sagen,
hört uns, wann ihr uns hören wollt, bleibt uns gewogen
morgens, mittags, abends, nachts beim Fahrradfahren
passt trotzdem ein bisschen auf
und bleibt gesund und
ja, bis zum nächsten Mal.
Alles klar. Tschüss. Tschüss. Ciao.