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.
Entschuldigung, dass ich wieder eingeschaltet habe.
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.
Hallo.
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.
Daher nicht viel.
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 man kann sich da anmelden,
irgendwie eintragen in so einer Testerliste.
Es gibt auch ein VSCode-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, aber wenn
das mal richtig gut funktioniert, irgendwie mit
Machine Learning dahinter wahrscheinlich so ein bisschen,
vielleicht einfach einen coolen Dockstring 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 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, direkt
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 der Leute ist,
hier und da zu schreiben, was dann dabei rauskommt, weiß ich nicht.
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
oder... Irgendwie so.
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 vor drei Tagen oder so rausgekommen.
aber ich weiß ehrlich gesagt
nicht mal, was der Unterschied ist.
Voll gut, nur so eine Erinnerung,
dass man das jetzt mal dann installieren könnte.
Aber ansonsten.
Nichts Großes passiert. Dann würden wir doch direkt
zur Folge kommen, oder fällt dir noch was ein, Ronny?
Ist doch eigentlich eine gute Überleitung, so GitHub
Packages. Stimmt.
Was ist denn das, ein Package?
Genau, das ist das Thema, ne?
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
oder ich weiß nicht, wo wir damit
anfangen, oder mit der Geschichte von
Packaging. Ja, okay, ich bin gespannt.
Ich hätte gesagt, es gibt noch DCP-IP, aber Entschuldigung.
Ja,
da gibt es auch Pakete, ja.
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 irgendwie 1998 mit
Distutils
und das ist auch
in der Standardbibliothek, ist da immer noch drin.
Also es geht eigentlich darum, wie gebt ihr denn euer Programm
irgendwem, der es dann ausführen
möchte? Ja, wie
kann man Code irgendwie,
ja, wie kann man Code so verpacken, dass man das
irgendwo anders dann halt einfach nur das Paket
installiert und nicht den kompletten, das komplette Repository.
Ja, oder vielleicht, wenn man noch nicht mal Python hat
oder so, oder der weiß dann 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...
Vielleicht ganz kurz noch, wenn wir jetzt schon mal wieder
bei Python-Podcast noch ein bisschen einsteigen.
Was ist denn DistroTilt?
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 B-Dist.
Aber ich weiß nicht, ob es da schon wirklich dabei war.
Ach so, ja.
Es 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
der Interpreter-Version ab und so,
Und dann gibt es halt die BDIS, also die Build Distribution Pakete, genau, 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 ZIP-File war.
und inzwischen sind es Wheels,
das ist auch mehr oder weniger der Fall.
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 schon immer schon lange.
So dass heute ist es halt so, es gibt halt Dinge, die macht Distu-Shills, wenn man ein Paket baut. Es gibt Dinge, da benutzt man Setup-Tools für, was ein bisschen komisch ist, weil das ist halt nicht in der Schaltebibliothek, 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 irgendwas,
was komplett werden muss, dann braucht man halt irgendwie
so einem Compiler und
muss halt
ja, dass dann halt auch da
Setup-Tools kein Konzept von
Cross-Compiling hat, muss man halt auch
für alle Architekturen, für die man Wheels bauen will
zum Beispiel, auch tatsächlich eine
Maschine da haben, die die Plattform
halt, also eine Maschine der entsprechenden
Plattform da haben.
Was halt auch unter Umständen so ein bisschen doof war.
Das war jetzt zu der Zeit, wo auf Apple Silicon
umgestellt wurde, haben ganz viele Leute plötzlich
gesucht nach, irgendwie habe ich irgendwo einen SSA-Zugang
auf eine 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 habe ein Paket.
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.
Ich habe jetzt auch hier so ein
M1-Mac 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 man sowas
installiert wie Python 3.9.6 irgendwie,
wenn es gerade mal 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.
Auf dem M1.
Ja, und einen zur Verzweiflung treibt,
wenn irgendwelche Details in dieser Compile-Pipeline
und irgendwann der Vortragskompiler nicht richtig ist
oder keine Ahnung, irgendwas bei der Emulation
des Intel-Prozessors nicht richtig funktioniert oder so.
Und dann kriegt man sehr, sehr komische Fehlermeldungen
aus den Tiefen von irgendwelchen Compiler-Toolchains.
Ja, okay.
Ja, also tatsächlich auf anderen Systemen bauen zu wollen,
an neuen Versionen, ist dann vielleicht immer nicht ganz so einfach.
Nee.
Aber das Gute ist, dass man tatsächlich auch,
wenn man jetzt, vor allem wenn man jetzt eigentlich 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 Komplexitäts-
Overhead sparen, indem man quasi
keine externen Libraries verwendet
oder sowas, ja. Genau, ja.
Also reines Python, das
ist eigentlich relativ einfach dann, ja.
Also das Einzige, was halt dann
mit in den
Build Distributions drin, das sind halt die
PYC-Files und
PYC, also ansonsten
muss die halt noch einmal von PY nach
PYC verwandelt werden, 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
über PIP oder
sowas.
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 so was,
Telefon auf Flugmodus stellen.
Das ist ja immer eine Checkliste
machen. Wird das ICQ-Bimmel im Hintergrund?
Du kennst das.
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.
Sozusagen, also es gibt auch einen schönen
Vortrag
eben von Daniele
Pruschida
über... Der ist schon wieder.
Der ist schon wieder, genau. Wie schreibt man eigentlich Dokumentationen
sinnvollerweise? Und der teilt das halt auf.
Naja, es gibt halt unterschiedliche
Quadranten und unterschiedliche
Zielrichtungen. Und dann schreibt man halt
Tutorials, How-To-Guides, Explanations oder
Reference-Documentation.
Und das macht 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 A 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 Referenzdokumentation.
Also sie haben das genau so aufgeteilt und sich daran orientiert.
Das fand ich irgendwie...
Muss ich auch mal machen für meine Dokumentation.
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.
Meistens ist man schon selber in einem halben Jahr und freut sich drüber.
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.
Ich habe mir mal irgendwo mal abgeguckt,
dass wenn man, sage ich mal, eine Methode hat,
die vielleicht 20, 30 Zeilen irgendwie relativ viel macht,
also du hast ein If und eine Schleife und keine Ahnung was,
dass man mit so Pünktchen arbeitet,
dass man sagt so, okay, hier mache ich jetzt das Punkt, Punkt, Punkt
und wenn das zutrifft, Punkt, Punkt, Punkt
und irgendwann kommst du halt zu dem Punkt, wo es halt vorbei ist
und dann passiert dieses und dann passiert jenes.
Das heißt, du kannst es halt mehr oder weniger wie so ein Buch lesen,
also genau den Pfad, der dich interessiert.
Habe ich mir irgendwann mal abgeguckt
und das mache ich eigentlich öfters mal,
ohne dass man jetzt da so einen fetten Dockstring drüber schreibt,
weil ich finde, der liest sich irgendwie.
Man ist ja irgendwie so ein bisschen faul.
Eigentlich gar nicht das Thema.
Ja, also wobei, ich weiß nicht,
bei Dokumentationen innerhalb von Sourcecode
oder Kommentare in Sourcecode 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 sieht.
Nee, das ist genau, genau, durchaus sinnvoll.
Aber, ja, von, na, wie heißt er noch, Dingsda, Clean Code, Uncle Bob, der sagt immer, das Erste, was er macht, wenn er durch Code geht, ist halt die ganzen Kommentare entfernen, 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, also jetzt in externer Sicht, 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.
Ja, wenn das gut strukturiert ist, gut dokumentiert ist, das lesbarer Code ist, vernünftig aufgeräumt ist, das macht schon echt viel aus.
Bisschen moderner Stil. Wir haben ja alle so einen gewissen Taste mittlerweile.
Ja, aber
wir sind gerade bei Dokumentation
gelandet, aber wir sind ja über Packaging
dahin gekommen und
ja, also okay, wir haben jetzt gesagt,
okay, 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.
Ja, das ist doch mal...
Ja, also wie man jetzt zum Beispiel die Metadaten zu einem Paket ...
Ah, Moment, man braucht Metadaten zu einem 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 irgendwie aus irgendeiner Init-PY in dem Paket selber oder solche Sachen. Aber auf der anderen Seite macht das halt der Infrastruktur darunter, dass es sehr, sehr schwer ist, dass das so dynamisch ist.
Bei Project Hummel 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-UI 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-UI ist für uns ein Riesenproblem eigentlich.
Also ich glaube, Setup-Chief-G ist viel
davon ist auch in PyProject-Hummel dann gewandert.
Genau, also PyProject-Hummel ist
mehr oder weniger ein neues Format dafür, ja.
Und das ist halt jetzt die aktuellste Art, wie man
die Metadaten sozusagen erfasst.
Und das ist halt auch Standard, ich glaube,
das ist PEP
518 oder sowas.
Irgendwie, glaube ich.
Ja, also das
wandert jetzt alles in PyProject-Hummel 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 habe ich in letzter Zeit
viel Gutes drüber gehört, ist Flit.
Oh, Flit?
Und es liest halt auch
PyProject Hummel aus
und baut halt Pakete.
Und vor allen Dingen benutzt es halt
nicht, glaube ich, nicht Setup-Tools, 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 fragte 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 noch 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 irgendwie
Talk Python to me, wo, nee, nicht
Talk Python to me, haha, falsch. Test & Code, glaube
ich, von Brian Ocken
der hatte da Brad Cannon
zu Gast
und der halt
irgendwie da
halt auch für diese Pipe EA irgendwie
wesentlich zuständig ist und
ja, der sagte also
er benutzt auch selber Flit und das
wird 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
N-Fax schmeißen müssen und dann habe ich
nochmal als irgendwie neu
von PyPI gezogen und
Pootree irgendwie Update gesagt oder Install, ich weiß es
gar nicht mehr genau und dann hat das irgendwie tatsächlich
geschlagene 300 Sekunden
irgendwie Dependencies aufgelöst.
Ja. So, wo ich dachte so.
Das passiert seitdem es das Async
macht. Ja, mir geht das
einstellen auf die Nerven. Da ist irgendwas richtig
kaputt, weil das darf nicht, also das kann
ich mir, ich kann mir nicht vorstellen,
wie das irgendwie, welchen
Grund es dafür geben könnte. Also ich meine,
ich weiß nicht, 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? Das ist irgendwie, 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 Pochi bringt ja einen eigenen Resolver mit und macht
das halt nicht über PIP. Aber offenbar
ist das irgendwie nicht so ganz okay. Also Pochi hat
mir schon so ein paar Mal
tatsächlich echt, ich dachte so,
okay, da ist irgendwas nicht
in Ordnung. Insofern...
Falls ich schon immer mal Open Source entwickeln wollte,
scheint es, als gibt es da ein paar Pull-Requests, die notwendig sind.
Keine Ahnung,
vielleicht muss ich mal reingucken, was da los ist, aber irgendwas,
also da kriege ich auf jeden Fall, wenn ich
sowas sehe, kriege ich einen Schreck.
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 da halt, das gibt's bei den
Setup-Tools,
gibt's
Setup, 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 das entwickelt, halt 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 das lädt quasi
seine lokale Datei
als Symbolink
Ja, ja, ja, genau.
Es ist nur in den, 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
sondern 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, dann denkt man erst mal,
ja, cool, du hast ja meist den Code irgendwo,
oder oft fängt man ja an, dass man denkt,
ah, ich habe jetzt was gebaut in meinem Projekt,
ich würde das gerne irgendwie generalisieren
oder vielleicht anderen Leuten zur Verfügung stellen,
was auch immer die Motivation sein könnte.
Und dann merkt man, ja gut, jetzt habe ich das,
jetzt muss ich es ein bisschen anpassen.
Ja, wie teste ich das denn jetzt?
Das ist ja jetzt ein eigenes Projekt,
das ist ja jetzt nicht Standalone,
das ist ja kein Django-Projekt in meiner Welt.
Was macht man denn dann?
Also dieses pip-e, das ist tatsächlich sehr, sehr cool und sehr einfach.
Also ich nutze in den meisten Projekten pipenv einfach, weil, ja, weil.
Ich habe gehört, Portree sei besser, keine Ahnung.
Nö, weiß ich nicht.
Naja, auf jeden Fall, ich bügele das dann halt einfach dann nochmal,
also alles mit pipenv 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.
Auch im einen ändert man halt dann
das Package erstmal 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 auch erstmal wissen, was man suchen muss.
Also du
hast auch schon mal so ein paar Pakete gebaut, ich glaube
auch, das hast du auch bei GitHub hochgestellt.
Genau, ja, ich habe
vor ein paar Jahren die
Ownership von dem Package
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 AIM Innovation, deshalb 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,
und dann ist dann halt die Jahre...
Also für die verschiedenen Projekte, das heißt, du kannst in jedem Projekt einfach sagen,
okay, den Code nehme ich jetzt immer mit und hab die Basis-Funktionalität
dann... Genau, ohne dass man es halt kopieren muss und
hat halt dann keine Code-Renundanzen und sowas. Und wie gesagt,
wenn man mal 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 man 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 es 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ähr, habe ich mal angefangen zu gucken, was ist da eigentlich drin, weil ich da selber
aber auch ziemlich viel contributed habe, weil ich halt
oft Sachen gebaut habe, wo ich dachte, ach, das ist cool,
das würde ich im nächsten 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, es gab keine Dock-Strings,
es gab überhaupt keine Art von Dokumentation,
also es war auch einfach nichts,
also man wusste halt, was drin ist oder man hat
halt im Code rumgesucht, aber war halt irgendwie
überhaupt nicht wirklich irgendwie
freundlich und in dem Zuge, dass ich halt
dann angefangen habe, ein paar Blogartikel zu schreiben, weil ich das
auch irgendwie ganz cool fand, weil ich dachte, hey, wenn ich das Problem
mal gelöst habe, das interessiert vielleicht auch jemand anders,
dachte ich, ja gut, das ist halt irgendwie, ich kann
da zwar einen Artikel drüber schreiben, aber eigentlich ist das
so ein bisschen eine Frechheit, wenn man das so lässt, weil das
halt nie, also in dem Zustand eigentlich nicht dafür da war,
dass man das wirklich nach außen irgendwie gibt.
Und das habe ich über 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 einen 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
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, ja komm, ich brauche
ist dieses neue Feature, das da drin ist, und man nicht
weiß, was man seitdem denn alles geändert hat
und nicht weiß, wie man dann 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 gibt es ja auch... Ja, genau, da sind wir ja, genau.
Semantic Versioning, glaube ich, habe ich gehört, ist da
en vogue.
Macht man das noch?
Ja, naja, nicht, also ich wusste es halt...
Wie man lustig ist?
Ich guck mal...
Ich habe gerade
einen Artikel,
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 Blog-Artikel von
Hüneck,
Hüneck, Schlaback,
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
nix, aber es ist halt, es ist alles
irgendwie. Vielleicht, was ist das denn?
Was ist denn Semantik-Versioning? 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 Punkt Minor Punkt 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ärtskompatibilitä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
keine Updates oder 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
darauf verlassen hat, dass sich etwas so verhält, wie es
jetzt halt tut und das aber ein Bug war.
Ja, das ist natürlich insofern
ja, aber
bei 0.9.7.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 0.96 auf 0.97 oder sowas und haben da aber einen neuen Check eingebaut, der nämlich gecheckt hat, ob F-Strings Variablen enthalten.
Und wenn du dann S-String oder Variablen hast,
dann ist es rausgeflogen.
Und plötzlich sind halt dann bei diversen Projekten
geht die Pipeline nicht mehr.
Dann so, 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 die den Bug repariert
und schon hast du auf einmal ein komplett anderes Ergebnis
und plötzlich ein Breaking-Change in deiner Pipeline.
Aber trotzdem.
Ja, dafür ist dann
Pult wieder ganz ruhig, wegen der Log-File,
wo es halt dann genau die Dependencies 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 Hash stimmt und so, ja.
Er würde dich auch nicht davor retten,
wenn da schon ein malicious Paket drin wäre.
Nee, dann hast du schon verloren, genau.
wenn es halt jemand später schafft, genau.
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.
Und das ist halt bitter.
Ja, ist schon doof.
Ich habe gerade ein Problem mit
auch 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,
die 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 Log-File
wegschmeißen. Toll.
Hätte man sich auch direkt sparen können.
Verlassen, dass dann halt das Dependency-Resolving
vernünftig funktioniert, aber
naja, da muss man halt doch wieder dann manuell pinnen.
aber das geht dann schon irgendwie.
Ja, aber solche Sachen, das ist halt wirklich hässlich dann.
Da gibt es keine richtig gute Lösung für.
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 eine Executable erzeugen möchte,
den 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 Web-Software.
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 zusammenschnürt, 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. Nuka. Es gab dann
Nuka, PyOxidizer. Wir
hatten da ja auch schon ein paar Mal drüber.
Inzwischen, wenn man auf die Tools guckt,
das sind Pi-Oxidizer und so, das ist schon wieder
alles verschwunden aus den Empfehlungen.
Das hat sich wohl
dann... Pi-Installer ist irgendwie
erstaunlich konstant.
Ich habe es noch nie richtig... Funktioniert einfach
nicht so, wie man will, wenn man zu viele externe 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 auch, ist natürlich so ein bisschen
verschwenderisch groß alles. Solange es
Docker noch gibt, ne? Ja.
Ja.
Aber, tja,
ja, nee, ich habe auch keine Lösung dafür.
Meine Lösung ist,
nicht auf Systemen unterwegs sein, wo das ein Problem ist.
Gut, aber es gibt halt
Leute, die halt andere Systeme nutzen, das ist ja klar.
Ja, ich verstehe das. Wenn die darauf relien,
und wenn man von bestimmten Konzernen,
die halt dann bestimmte Policies haben, die man nicht
verstehen muss, aber wo man das natürlich daran halten muss.
Die haben bestimmt 1998 Sinn
gemacht, dass die jemand eingeführt hat.
Ja, also die sind auch veränderungsresistent,
da würde ja die ganze Abteilung sich als Renonant
erweisen vielleicht, aber
solange die 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 die Semantic Versioning,
man kann halt damit wenigstens versuchen,
dass man halt dem
Nutzer, den man ja meistens nicht kennt, so ein bisschen
wenn die, ja, den Pain
zu nehmen, wenn man halt, wie man mit Updates umgeht,
weil jedes Update, je nachdem, wie groß das Projekt ist und
auch, wie stabil das Projekt ist, so
Stichwort Testing und sowas,
kann das ja auch ziemlich, mit ziemlich
viel Kopfzerbrechen verbunden sein, irgendwas
überhaupt hochzuziehen und
bei dem habe ich jetzt halt gesagt, hey, wir
machen jetzt 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 hat irgendwie komplett
alles auf drei umgestellt, ist halt ein Breaking Change,
musst du halt hochgehen, da kommst du 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
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
irgendwie vernünftig zu erreichen, zumindest
nicht direkt und
da sollte man ja schon
gucken, dass man das
ja, so stabil wie möglich baut.
Ja.
Ja, ja.
Ja, ist auf jeden Fall nett.
Ja, also ich wollte gerade sagen, also
ich glaube, manchmal machen die Leute auch so ein bisschen zu viel
Schwurbel um, es muss
backwards kompatibel sein für
bis in alle Zeiten.
Absolut. 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.
So, ich meine, wäre halt einfach...
Ja, es wäre schon nett, wenn man halt die Versionsnummer dann vielleicht major ändert.
Genau, also 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 du das dann auf?
Schreibst du dann vor jedem Commit
oder lässt du aus den Commit-Messages automatisch dein Log kriegen?
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.
Das ist einfach ein Markdown-File.
Disziplin, vernünftig deine Arbeit zu dokumentieren.
Ja, und vor allem, das sind ja auch Stichpunkte.
Ich meine, inzwischen habe ich eine Dokumentation,
da kann ich gleich noch was dazu sagen.
Auch ein Thema für sich.
Aber ich habe einfach ein Markdown-File
und das ist halt eine lange Liste, wo dann halt drinsteht,
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 meine, 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 jetzt 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, Change.org zu schreiben,
wenn ich jetzt noch nichts habe, was richtig fertig ist und was
funktioniert. Wahrscheinlich bei Person 1.0
würde ich auch. Irgendwie so, ne, ja.
Oder sobald halt Leute anfangen, das zu
verwenden irgendwie. Was du natürlich auch nicht so genau
weißt, also. Ne. Ja, sobald
du was einigermaßen Nutzbares irgendwie hast,
vielleicht. Ja. Genau.
Ja, ich überlege gerade, ob ich was nicht so mache und denke mir so, oh nein, ich breche trauernd die Komplimente.
Ich meine, es kommt auch 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.
Wie so der Werkzeugkoffer bei euch im Schrank. Da hängt auch alle möglichen Schraubenschlüssel rum. Jeder hat seinen eigenen Werkzeugkoffer mit eigenen Schraubenschlüsseln. Tauscht man zu selten aus. Und da sind aber die Farben, die hat man sich selber zusammengesucht und man weiß selber, wo man in der Kiste was findet. Aber wenn jemand anders da in diesen Werkzeugkoffer reinguckt, dann, ja.
Genau, also ich finde es eigentlich cooler, wenn man das, ich meine, da muss es nicht auf JavaScript-Level gehen, wo die quasi jeder zwei Zeilen ein eigenes Package ist, das ist manchmal ein bisschen krass, aber wenn man die Sachen vielleicht auch ein bisschen, also sagt man so, würde ich jetzt das Package nicht geerbt haben, sondern würde es jetzt neu machen, dann würde man sagen, hier dieser Code, der soll irgendwie Packages, würde ich das wahrscheinlich nach gewissen Use Cases strukturieren.
Also auch nicht mehr Core nennen, sondern tatsächlich den Funktionalitätsgebiet.
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 oder das heißt halt Core
oder so. Das ist
ja, das ist ganz, ganz typisch.
Aber wie gesagt, zum Beispiel
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 so, das hat dann auch gewisse
Dependencies, die man ja sonst nicht reinholen muss.
Das ist dann auch
ein eigenes Paket. Und ich habe das jetzt mit
Extensions tatsächlich gemacht, weil am Anfang
war es auch so, dass auch die ganzen
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 tatsächlich sagen, dass man verschiedene
Extensions macht. Also das kennt man, wenn man das
aus dem Requirements oder so
ist, so eine enge Klammer, wo dann irgendwie
bei Celery kann man es mit SQS oder
mit Revit 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 steht es dokumentiert
und sage, 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 da müsst ihr
halt noch die Extension mit installieren und dann
kriegen die halt auch die
Dependency.
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
machen wir das halt sehr modular?
Also ich sag mal so,
du kannst ja theoretisch
auch einfach alles installieren, wenn du es willst.
Das ist relativ zentral. Steht das auch am Anfang, hey, das gibt es
und wenn du nicht so genau weißt, dann kannst du einfach alles nehmen.
Aber ich finde es halt schön den Leuten, die halt
mehr Kontrolle haben wollen, die zum Beispiel sagen wollen,
hey, ich achte drauf, welche Unterdependencies
in mein Projekt reinkommen, weil ich halt keinen Knatsch
haben möchte oder sowas.
Denen halt die Möglichkeit zu geben. Und dann auch
ganz wichtig, dass man die ganzen
Build-Dependencies, die man
wirklich nur auf Meta-Ebene,
also wenn du am Package arbeitest, dass man die halt
rausnimmt, weil das bringt halt unendlich viele Sachen
sonst nachher in so ein Projekt rein, den man eigentlich gar nicht haben
möchte. Genau, ich habe
jetzt hier gerade nochmal
das letzte Paket, das ich irgendwie
gebaut hat und 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 habe ich da 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 uns anstellt und wie man dann so entwickelt,
wie man das live macht. Ja.
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
sehr spannend ist, was man da alles so umsetzen kann.
Ich baue das gerade so ein bisschen nach, ehrlich gesagt.
Ich habe... Also Final Responses fand ich
sehr interessant, den möchte ich auch mal bauen, ja.
Also wo ich tatsächlich noch Schwierigkeiten... Ich merke das, das habe ich
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 immer 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 in einer halben 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.
Also das merken, weil normalerweise
würde mir das halt nichts ausmachen. Mir macht das ja Spaß,
das zu entwickeln. Und dann probiere ich halt rum
und wenn es halt geht, super. Wenn es nicht geht, naja.
Ich muss sagen, also mir macht das 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 das so ein bisschen rausknobeln muss.
Und man ist ja quasi mit live dabei. Das ist ein bisschen
vielleicht wie am 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 sowas, glaube ich,
tun, ja. Ja, das ist tatsächlich vielleicht eine interessante
Geschichte, dass man genau da bei Leuten
halt so, aber wenn man das macht oder
für mich war das überraschenderweise so,
dass ich das Gefühl habe, oh, jetzt muss ich aber weiter
oder oh, da sehen Leute, dass ich keine Ahnung
habe oder weiß ich nicht, irgendwie so ein
Ego-Ding, dass ich nicht so
richtig los werde und da ist mir jetzt schon ein paar Mal
aufgefallen, okay, da habe ich dann irgendwas übersprungen oder
dann bin ich nicht so, mache ich das nicht so, wie ich das normalerweise
machen würde. Also ich weiß eine Lösung.
Also du hast ja so ein tolles Pult,
da kannst du so bestimmte Einwendungen machen. Ich würde so
einen Button dann einfügen, den kannst du zumindest später
runterschalten, wo dann einfach so fett zensort auf dem
Bildschirm steht, so ein schwarzer Balken,
dann wird das, was du gerade programmierst, einfach kurz sensiert und
der Ton gestrambelt, dann gehst du so
selber kurz draufdrücken, dann hast du einen
kurzen sensierten Teil, dann kannst du
wieder freischalten, dann, okay, geht wieder.
Ja, genau,
wird sich schon irgendeine Methode finden.
Kennt ihr das aus Starship Troopers, wo es dann kurz diesen
Send-Out-Biken gibt und in den Hintergrund werden die Kühe dann von den Elfen vergessen?
Ja, und hinten wie so 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-Fire-Response-Paket gebaut.
Da habe ich etwas verwendet, was ich jetzt vielleicht dann
auch nur aus Spaß
habe ich
ein MBDev, was in der Data Science
welther so ein bisschen
verbreiteter ist. Vielleicht nochmal ganz kurz, das hast du auch schon
einmal kurz erklärt, aber NBDEF 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 Literate Programming
machen kann und halt
Dokumentation, 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
Extras Require zum Beispiel
und kann dann
halt, das ist einfach nur ein Dikt und
dann kann man da beliebige Dinge reinschreiben, halt zum Beispiel
was ich jetzt da nur drin stehen habe, ist halt Dev und dann
Dev Requirements, aber man kann halt auch eben
eben alle möglichen optionalen Geschichten mit
angeben, die man dann halt installiert oder nicht und
da wäre es zum Beispiel so, also dieses
Django-File-Disponse-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 Envy-Dev-Kram mitkommen zum Beispiel.
Es würden Jupiter-Notebooks mitkommen,
es würde Pandas mitkommen, es würde Nam-Pi mitkommen,
es würde irgendwie so das
halbe Deadline-Universum
mitkommen, was du normalerweise
auf dem Web-Server hast, wo du Django
verwenden willst, hast du es ja gar nicht. Und plötzlich
wird dann wahrscheinlich irgendjemand
vor einer Konsole sitzen und denken sich,
warum kommt da jetzt ein Fortran-Compiler
mit Telefon drin? 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
nutzbar ist?
Muss ich da quasi ein anderes Notebook nehmen
oder kann ich einfach ein Jupyter-Notebook nehmen?
Das ist ein Jupyter-Notebook, aber das Einzige,
was man da braucht, ist im Grunde
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 nach vorne machen würde?
Nee, das ist keine Extension,
sondern das liest es einfach nur.
Und wenn man da sowas reinschreibt wie Kommentar
und dann Export oder Default Export,
also 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.
Dann wird das gelesen von der MBDF und das schreibt dann halt
den Source-Code dann raus.
Also ich fand's eigentlich ganz nett.
Ich find's auch sehr spannend, also sehr cool.
Ich benutze auch relativ viele Notebooks zum Entwickeln.
Also gerade auch so Django, so I.O. Sachen oder sowas
oder Modellsachen, Funktionen, Methoden.
Die kann man einfach super schnell
dann testen. Die gehen halt an, Django-Shell 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 öfters ich oft mit dem Debugger
entwickle. Ja, das ist auch eine interessante Option.
Ja, auf jeden Fall. Das mache ich
nicht so oft, aber das wollte ich mir auf jeden Fall
auch nochmal angucken. Du nützt ja auch
PyCharm, ne? Das ist, glaube ich,
sehr komfortabel. Ja.
Man muss sich auf jeden Fall abgewöhnen, STRG-S zu drücken.
Ja. Weil dann speichert ihr die Datei
und dann fliegt der Debugger raus. Ja. Aber
ich finde, das ist eigentlich ganz cool.
Also vor allem, wenn man so viele Funktionen
und so irgendwie externen Daten und sowas bekommt,
wo man dann oft irgendwie,
okay, da muss ich mir auf die dritte Area-Stelle zugreifen.
Das sind Sachen, die man halt, du weißt, es ist da irgendwo,
du weißt nicht genau, wo es ist.
Und da macht man dann normalerweise viele Runden
und das ist dann einfach angenehm,
wenn du dann direkt einfach in diesem Evaluate-Expression
einfach die Sachen da zusammenklopfst
und dann direkt auf den Knopf drückst und weißt,
jo, läuft, passt, nice.
Ja, da muss ich auch wieder ein Land zerbrechen,
das geht auch in anderen Entwicklungsumgebungen
tatsächlich ganz gut, wenn man die richtig einstellt.
Das haben wir so ein bisschen gefummelt,
bis man halt den Debugger so laufen hat,
wie man das gehen 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 Django-Debugger,
der relativ coole Sachen machen kann,
wie Visualisierung der Code-Pathes und sowas.
Cool.
Relativ geil, musst du mal 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 Konfiguration zeigen,
ein bisschen so die Magie zeigen, wie man das Tool dann jeweils benutzt.
Das ist, glaube ich, auch noch mal sehr lehrreich.
Also vielleicht kurz darauf eingehst,
so wie man es da so nachmacht.
Kann ich mir einfach mal vornehmen, das zu versuchen zu verwenden.
weil dann, also 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, das ist
ganz wichtig.
Ja, wenn man sonst immer noch bei seinen Sachen bleibt, dann wird man darin
auch ein bisschen besser, aber was neue Sachen ist, ist schon spannend.
Ja, ja, oft. So was 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 so noch zu erzählen.
Aber ja, ist noch wahr.
Das Gefühl geht auch nicht weg.
Ja, okay.
Ja, 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ößer anstatt kleiner.
Das ist so ein bisschen das Problem.
Ja, weiß nicht, was mir bei so zunehmender Erfahrung auffällt,
ist oft,
muss ich gar nicht mehr so
oder was mir heute leichter fällt
oder ich sag mal so, 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 probiere ich halt einfach rum
und dann hinterher denke ich so, okay, das war's, aber keine Ahnung.
Ich weiß gar nicht, ich habe mir jetzt gar nicht genau überlegt, was ich
da tue, sondern es passiert irgendwie.
Das passt mit dem Blogartikel, den du mir letztens geschickt hast,
wo du sagtest, wie lange sollte man eigentlich
über Probleme nachdenken? Und die Antwort war eigentlich
so, ja, eigentlich gar nicht.
Genau, würde ich auch inzwischen
sagen, eigentlich lieber, wenn man
nicht direkt weiterkommt, halt einfach was anderes machen.
Später nochmal drauf zurückkommen.
Duschen gehen, es fällt einem wie Schuppen von den Augen.
Aber das ist ja auch direkt eine gute Überleitung.
Ja.
Weil bei Packages ist ja auch oft das Problem,
dass wenn man entweder auf der
gebenden oder auf der nebenen Seite des Packages steht
und dann einen Bug hat,
beziehungsweise auch irgendwie so eine gewisse Maintenance machen
muss, zum Beispiel gibt es eine neue Dango-Version und man wird
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
und 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.
Nee, wegen Bugs und Problemen.
Ja, wie lange man nur dran 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 den Code so gebaut, dass es halt funktioniert.
Und dieses Package ist halt irgendwann mal hart abandoned worden.
Also, dass da wirklich die Leute einfach kein Interesse mehr daran haben.
Also, die nicht mal mehr das Interesse haben, zu sagen so,
hey, ich schreibe einfach sorry, ich weiß ich nicht,
ich 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.
Und das ist halt immer wieder sehr ärgerlich.
Und ich glaube, dass wenn man so ein Paket in die Welt setzt,
und 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 prominent eine Möglichkeit hat,
dass man den Leuten Feedback geben kann.
Also offensichtlich ist es einfach bei GitHub, die Issues.
Die kann man übrigens auch sehr schön über die,
zum Beispiel Setup Highlight oder Project Setup Tommel,
direkt verlinken in PyPy,
dass die Leute direkt,
über das Change-Log 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 Übersetzungshelfer 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 translatet, dann kommt irgendein Unsinn raus.
Genau, und das hat mich dann total gefreut, es kam auch direkt ein Pull-Request hinterher, hey, hier so und so, und hab dann auch die Übersetzung nachgezogen und alles super, ne, also hätte ich sonst niemals rausgefunden, weil bis die irgendwie dann über 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 Convenience,
die man dann seinen Usern irgendwie
bereitstellen kann, weil es kostet ja auch nichts, es ist ja echt schnell
gemacht. Und wie gesagt, das andere
mit der Maintenorship, 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 mit 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 nutzt 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 da jetzt irgendwie Interesse und ich muss das reparieren
und sage, gut, ich habe selber keine Zeit, dann mach halt.
Ist immer noch besser, als 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,
es ist halt einfach nur viel Zeugs inzwischen
und
ich würde das ja schon gerne alles noch machen.
Ja, also manchmal möchte man halt auch mal
in den Garten gehen oder sowas.
Nein, das hatte ich jetzt gar nicht gesagt.
Nein, nein, also das ist ja kein großer Wille.
Aber dass man halt irgendwie,
dass man dann vielleicht wenigstens noch ab und zu auf GitHub
guckt, wenn jetzt einer sagt, hey, geht nicht mehr, dass man dann
sagt, ja gut, dass man den Leuten vielleicht kommuniziert
einfach so, hey, sorry.
Dann würden wir nicht sagen, wir lesen wahrscheinlich noch
so Nachrichten oder so.
Aber es ist auch die Frage, wenn du irgendwie 5000 am Tag kriegst
oder so, das ist wahrscheinlich dann auch anstrengend.
Je nachdem, welche Größe du hast irgendwann.
Das kann auch sehr overhelming werden.
Also gerade, ich sag mal, das Leben von Leuten
ändert sich ja auch oft. Also so 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 jetzt den 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 den 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
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 die selber
Sachen merchen können oder die Interesse dann haben.
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 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,
da hat sich halt im letzten Mal auch was getan, da bin ich jetzt
auch mal da beigetreten.
Und dann, weil ich habe
nämlich gesehen in dem Projekt, in 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.
Cool.
Dann löst du quasi dein Problem
und hilfst aber noch ganz vielen.
Ja, gut, das 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.
Ist vielleicht auch eine kleine Verbesserung.
Ja, ja.
Tja, was haben wir denn?
Was gibt es denn noch
so für Dinge, die wir über
Packaging irgendwie
erzählen sollten?
Habt ihr irgendwie
irgendwelche Tools, die ihr
bevorzugt verwendet? Also Flit, okay, kanntet ihr jetzt
nicht. Habe ich auch nicht.
Werde ich dann demnächst mal ausprobieren. Mal gucken.
Das ist irgendwie voll gut.
Ja, Poetry
verwende ich meistens, aber
Ja, tatsächlich so zum normalen
lokalen Verwalten schon und zum Bauen.
Du verwendest pipenv, aber das ist nur
für die
Genau, nur für die Requirements.
Ja, genau.
Tatsächlich, das Package,
das schiebe ich noch
mehr oder weniger genauso hoch, wie das damals
2012 war, also so eine ganze fiese Set, also
das heißt fies, aber aufgeräumt ist sie aber eine
sehr angestaubte Setup-High.
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 es 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.
Ich meine, gut, dass du das gesagt hast.
das werde ich dann in ihrem Nachgang mal anschauen, weil
ich hatte eh schon immer mal überlegt, ich würde da gerne
was machen, aber wie du schon auch gesagt hast, es gibt
so viele Wege, die nach oben führen und wenn ich jetzt gerade keinen
unbedingten Druck habe, was
zu ändern, dann ist mir dann auch so eine Sache,
die auf der To-Do-List dann gerne mal ein bisschen nach hinten rutscht.
Ja, ja, auch in diesem, auch in
der Episode mit Brad Cannon, der meinte halt so,
eines der Hauptprobleme, die sie so haben,
auch irgendwie, also der
Grund, warum das alles so zersplittert und kompliziert
ist, ist halt auch, dass
der Haupt
Weg, 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-Wi-Fi geschrieben und
das kopieren sie halt Projekt von Projekt
zu Projekt immer weiter. Und 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 oder
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
ja, 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, ja. Das klingt aber
auch alles schon wirklich, also ganz im ganzen
Packaging-Ding, ne, so gordischer Knoten.
Ja, das ist wirklich gemein, ja, 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.
Wegschmeißen, neu machen, auf Features verzichten, vielleicht braucht man
die alle gar nicht.
Ich habe das Wesentliche
konzentriert.
Ja, aber genau, ich habe auch einmal so ein
Cookie-Cutter-Template verwendet, also es gibt ja auch
Python-Package
Cookie-Cutter-Template von
Pied Denny. Genau.
Und das fand ich
auch ganz nett, aber... Der übrigens auch auf Twitch streamt.
Bitte? Der übrigens auch auf Twitch
streamt. Ja, ja, richtig, genau. Das habe ich mir auch schon
so ein bisschen
angeguckt. Genau, fand ich auch gut.
Ja, okay.
Was ich auch ganz interessant finde,
apropos Projektsetup,
der Code, der jetzt in meinem Package drin ist,
der ist natürlich auch logischerweise getestet.
Also am Anfang war nicht so viel getestet.
Logischerweise, natürlich, Ronny.
Inzwischen ist er getestet, zumindest Großteils.
Also 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 gebandelt wurden.
Also die Metatests quasi,
also die Sachen, die das testen, was ich nachher ausliefere,
mir ist dann nachher mal aufgefallen, die muss ich ja gar nicht mit ausliefern.
Weil das interessiert einfach keinen.
Vielleicht ist es ja 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.
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. Da habe ich mich mir direkt,
als ich dann diesen besagten Bug mit den Übersetzungen
gefixt habe und natürlich
dann auch das erste Mal eine Pro-Datei
in dem Projekt hatte, die waren
natürlich nicht mit eingeschlossen. Das heißt,
ich bandele das Ding wunderbar und dann
klappt es halt nicht. Ich sage, das hat doch gerade lokal noch
funktioniert. Ich bin auf die Idee gekommen, ich gucke mal
in das Package rein, das installierte, ob das
weil ich hatte es natürlich auch vorher mit Minus E installiert,
also um es zu testen, da ging es mir natürlich
und ja, also wenn man da
irgendwie mal neue Dateiformate dazu baut, dann muss man
die auch nochmal explizit angeben, je nachdem wie man es
hat, ob man halt einschließend oder ausschließend hat, aber
ja.
mit den kleinen Hürden. Ja, das ist auch eine der häufigsten
Sachen, die, wenn man so
oder wie mir passiert, wenn man so ein GitHub-Action-Pipeline
hat, die halt auch testet und so,
das lokal funktioniert alles
und dann macht man 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... Also ich würde sagen, war fast besser
als andersrum, weil dann fällt es einem ja direkt auf und dann kann man
es einbauen und so. Ja, das ist wahr.
Dafür sind ja Pipelines dann auch da oder dann die E-Mail
immer bekommt, dass das schon wieder kaputt gegangen ist oder so.
da ist ja ganz praktisch
ja
Stichwort Pipelines
hatten wir 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, oder?
Ja, die Tox-File, genau
und Travis nutzt das dann
Man kann da einstellen, wie viele verschiedenen Python-Versionen das einmal durchtragen
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.
Ich habe immer keine Lust auf Backward Compat.
Ich will immer die neuen Features drin haben.
Das Coole ist halt ...
Das nutzt aber auch keiner, deswegen ist es auch egal.
Das Coole an dieser Matrix ist halt,
dass man halt erstens die Sachen halt
sicherstellt. Also das, was man
angibt, das geht. Das geht dann auch wirklich.
Das ist halt sehr, sehr praktisch, weil wie schnell ist es,
dass man sich bei, weiß ich, vor allem wenn man so
Django-Admin-Extensions oder sowas baut, da erinnert sich ja so schnell
mal irgendwas und dass dann plötzlich in irgendeiner
Version irgendwas kaputt geht, der noch nicht da ist.
Und das manuell zu testen, ist ja
verrückt. Aber 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 Newscase, den man halt im
normalen Verfahrensbereich nie hat. Also was ich auch
sehr cool finde, sind diese ganzen, wenn wir jetzt
bei GitHub schon sind, dann 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
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
direkt 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 da 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 da vielleicht was zu
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 Produktionsumgebungen
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 Jammelfiles, 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 Versioning, tolles Versioning,
Ich habe auch Semantic-Versioning eingebaut und ich wollte halt
einfach die Version bekommen. Und da der Punkt, wo ich
die Versionsnummer pinne, meine
Pipe-Projekt-Hummel war oder ist,
da habe ich mir gedacht, okay, ich passe die einfach und benutze
die dann weiter. Und 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 wäre eine Pipeline erst noch aneinandergeflogen, weil ich einfach den Rack-Ex
falsch gepasst hatte. Aber solche Kleinigkeiten halt,
dass halt sowas weg ist.
Das ist halt lustig, aber solche kleinen Sachen,
die führen halt immer dazu, dass eine Pipeline läuft, die
manchmal ziemlich lange dauert.
anderthalb Stunden oder länger.
Ja, das klingt nach
ein Problem, ehrlich gesagt.
Ja, das ist nicht lustig und man hat
halt auch irgendwelche Regeln von außen, die man gar nicht beeinflussen kann,
die man sich halten muss und
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.
Sowas, 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 Produktion
zu updaten. Und damit uns
halt da nichts schief geht, müssen wir halt
erstmals nachbauen. Das dauert halt dann immer doppelt so lange.
Oder zweimal neu bauen musst.
Und dann musst du am Ende, weil wir halt
Budget und so, musst du halt die ganze Station-Gegend erstmal wieder abreißen,
bevor du die Zone anfängst 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. Ich glaube, das war in Kopenhagen, ich glaube, das war vorletztes Mal. Das ist einfach, ich habe es halt auch gemerkt, dass jetzt, also selbst in meiner eigenen Firma, wo ich ja echt jetzt keine weiten Wege zu den Leuten habe, wenn ich sage, hey, da ist das drin, nutzt das mal, das ist halt eine Blackbox.
Also selbst wenn du dann irgendwie, dass sich dann 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 jetzt tatsächlich auch im letzten Quartal relativ viel gemacht und habe da mal bei Read the Docs da so ein bisschen Markdown mit Sphinx gepublished, also Sphinx kompliertes Markdown.
Auch ein bisschen nervig mit Restructure-Test geht das immer besser.
Ja, ich komme mit dem Dokumentformat irgendwie nicht.
Nein, das ist recht, aber Sphinx macht das halt sehr ungern mit Markdown.
Ich weiß, ich habe da mehrere, ich habe da so ein paar Adapter.
Ja, 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 zwischendurch 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,
so, das ist 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, also dass du sagst, hey, guck mal, ich habe diesen Use-Case, ich möchte wie Dartmark anonymisieren, habe ich hier irgendwie einen Rapper, der hilft dir.
Oder wenn du irgendwie E-Mails testen möchtest, da habe ich hier eine Fernsehklasse oder ein Mix-In, das hilft dir, dass man die Leute auch ein bisschen abholt und erklärt, warum willst du das denn ü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 in 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 Dockstring dann auch so reinschreiben, was das 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.
Ja, also, das ist auf jeden Fall
eine gute Idee.
Und weil dann ist auch die Dokumentation
in Ordnung. Also, was ich
bei Dokumentationen oft merke, das ist,
finde ich sehr nervig, 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 das läuft, und 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. Also da hatte ja
der Kalten Gipsen jetzt bei
dieser DjangoCon einen Vortrag bezüglich
wie dieses Static Dynamic Websites,
Static Dynamic Pages
hieß es, glaube ich. Ja, mit 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 Strings 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 da
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
irgendwie separat gehostet und
wenn du jetzt, bei Packages ist es eh schwierig,
weil die laufen ja nirgendwo, wenn das zum Beispiel sagt,
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 ging das nochmal mit dem Backup oder so, ja. Genau,
und 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 ja, Moment mal, du hast da was angefasst,
du hast dann das
Markdown nicht dazu angepasst.
Das sind, glaube ich, sehr, sehr coole Use-Cases. Dafür wäre man
da halt wirklich, wenn das wirklich wichtig ist,
du hast halt dann die Nähe
von Dokumentation, die eigentlich sich weit weg anfühlt,
das ist irgendwo ein Marktunterteil, 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 das näher bringt und damit auch die
Motivation erhöht, dass man es auch wirklich tut.
Also ich war ja echt Fan auch von diesen autogenerierten
Sphinx-Docs, ja Autodoc aus den Docs-Sphinx heraus
und so, dass einen halt so ein bisschen dazu zwingt,
den Docsings aktuell zu halten. Aber noch
besser sieht das tatsächlich, jetzt muss ich noch kurz
verjochen und langsam brennen, dieses NBDEV aus, weil
man in Notebooks halt das Markdown auch direkt
mit reinschreiben kann, wenn das ordentlich
aussieht. Man Notebook hat, was ordentlich aussieht
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. 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 so,
gerade bei Data-Science-Geschichten
ist es besonders schön, weil das halt
zum Beispiel, man hat ja oft dann
irgendwelche Visualisierungen.
Die Visualisierung ist natürlich besonders.
Das hast du ja sonst eigentlich, weiß ich nicht, wenn du jetzt
ein Django-Paket hast oder so, hast du das im Grunde kaum.
Insofern ist es da nicht so schlimm,
wenn man das halt nicht 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 du halt nicht erst
Paket bauen, also den Pull-Request
bauen, den angucken, dann
die Visualisierung dir anzeigen, erstmal bis dahin kommen.
Das 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 total interessant.
Es gibt da 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
ja,
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.
Vite, ja, ich bin da auch,
das ist auch so blöd, wenn man dann irgendwie,
da habe ich auf irgendeinem
Vue Meetup einen Vortrag
über VitePress gehalten
und dann VitePress gesagt
oder sowas und dann kam die erste
Frage und jemand hat gesagt, Vite.
Ich hab's gerade gedacht.
stundenlang jedes Mal falsch gesagt
und ja, aber
genau, so ist das halt und
das ist aber, das ist 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
während mit Sphinx und so, das ist ja dann doch
eher so, man muss das erstmal dann irgendwie
bauen und das dauert alles ein bisschen, bis
dann auf der Webseite ist, dauert nochmal, also
während bei Beatpress oder so,
das ist halt sofort da, man editiert das quasi live,
das ist halt auch
ach, 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, aber
Also ich würde auch fast sagen, also
Weedpress irgendwie, also so
ist schon nett für Markdown-Sachen,
Markdown-Sachen husten oder hochladen, aber das generiert
halt immer noch nicht deinen Content, ne? Den muss man halt immer noch
selber schreiben, aber man
kriegt den damit sehr gut aussehend hin, also die ganze
also ich meine, die View-Dokumentation
ist ja View-Press, weil das kann halt
auch mal ein bisschen mehr, aber
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
also die Vue-Dokumentationen
sieht schon besser aus.
Und also das sind ja auch so kleine
Animationen und diese ganzen Geschichten, die halt bei Vue
so drin sind. Ja, es ist relativ
einfach, dass da 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 ja, wenn man das halt hat, das macht man halt zum Beispiel
wieder nicht, aber das ist halt dann unheimlicher
Overhead, das dann halt in die Projekte dann alles mal reinzubringen
und man muss halt eigentlich an mehreren Stellen dann 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
lieber möchte.
Dass es allerdings war.
Ja, Pakete. Jetzt hast du noch was,
Ronny, du hast das noch.
Also tatsächlich, ich habe
jetzt noch so zwei, drei Kleinigkeiten, die
mir jetzt aufgefallen sind, dass 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, wird ja kontrovers diskutiert,
ob das jetzt 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 dem eigenen
Scope kommen, weil du halt dann super schnell in 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 ist das abstrakte
Django-Ding, ja. Aber
ich finde das halt super praktisch, also vor allem
also... Aber ist das nicht falsch?
Also wenn du halt
eine... Ja, es ist halt
der Vater, ne? Also es ist ja
immer Typ Query-Set. Ja,
na, ist dann nur die Base...
Aber das ist schon, glaube ich, auch
wie man das, man sollte halt irgendwie
die Abstraktionen von der halt abhängen
und die dann halt auch. Also im Endeffekt, wenn ich halt
nix zurückgebe, also nicht halb hinter,
dann weiß jemand nix. Wenn ich weiß, da kommt ein Query Set
zurück, dann weiß ich immerhin schon mal, ey, das ist keine Liste.
Ja, 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, wo dann halt die Typen
existent sind, die man aber auch verwenden muss, weil
ansonsten ist das ja falsch. Also wenn du jetzt ein User Query Set hast,
Vielleicht hast du ein Custom-Query-Set,
wo du irgendwas Besonderes dran gemacht hast,
irgendeine Methode, die andere Query-Sets nicht können.
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-Inputs
noch nicht gelöst habe,
und ich auch gar nicht weiß, was es für eine Lösung gibt,
habe ich mich einfach dafür entschieden,
ich gebe dem Nutzer halt einfach
einen Ticken mehr
Informationen mit.
Verantwortung.
Also meistens finde ich es eh, also sehr sinnvoll
ist es vor allem eh bei trivialen
Datentypen, weil du halt dann, ob es jetzt irgendwie
Decimal oder Float oder ein Integer oder sowas ist,
das macht ja schon, macht ja 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, ist das total praktisch, dass
dir dann direkt die Idee schon anzeigt, so sorry,
da stimmt irgendwas nicht. Genau, das ist, finde ich, auch das Wichtigste
an diesen Type Lins in Python, dass du halt tatsächlich, wenn du
den Lint richtig konfiguriert hast, während
im Schreiben siehst, wenn du da irgendeinen
Anspruch hast und das ist wirklich praktisch. Aber ich
mündest auch tatsächlich meistens nur für komplexe
Dinge, also wo es fraglich ist oder wo du 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.
Und dann machst du Komma, Sternchen, Komma
und danach deine anderen. Und dieses Sternchen
sagst du dem quasi, es kommt hier
quasi kein normales
Argument und dahinter kommen die Keyword-Argumente.
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 es nur Keyword-Argumente. Genau. Und das
finde ich, also bei manchen Sachen ist es natürlich Unsinn.
Ich meine, wenn du eine Sache hast, wo 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 3, 4, 5
Sachen reingehen, was ja irgendwie auch so
ein bisschen unlesbar ist. Ja. 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, man möchte irgendwas da vorne rein, dann
kann man das einfach machen, weil es ist ein Keyword-Argument.
Aber das schluckt ja nicht das mit dem ständigen Rest einfach weg dann?
Ich überlege gerade, wo der dann rausfällt.
Äh, nee, man kann auch noch ...
Also der Argument wird ja wegschlucken,
die würden einfach nicht mehr auftauchen,
aber die werden halt nicht in den Keywords dann gemappt,
die man eigentlich ...
Nee, der macht dann tatsächlich einen Fehler.
Der wirft da gar nichts, darf nur nicht.
Also das ist sehr praktisch, weil ansonsten,
das wäre ja blöd, wenn das passiert, was du sagst.
Nee, tatsächlich sagt er dann,
sorry, da müssen Keyword-Arguments drin sein.
Okay.
Und das finde ich, wie gesagt, es gibt Methoden,
da macht das keinen Sinn,
aber wenn das irgendwas sehr, sehr Wichtiges 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 du es du bist oder jemand anders, mehr
Semantik erzwingst.
Ja.
Also explizit nur Keyword-Arguments
erlaubt. Gibt es da nicht doch irgendwie ein Parameter für?
Es gibt da irgendwas mit dem Slash, ich weiß es
nicht mehr genau, es gibt, aber ich weiß
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, ja,
ich würde jetzt sagen, genau, wenn man
viele Argumente hat, dann ist erstmal,
also ich würde sagen, naja, es gibt schon mal Fälle,
wo das gut ist, aber, 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's
vielleicht, aber ansonsten
Wenn man ja immer durchpipen muss durch
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, 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 irgendwie besser machen.
Ja, aber ja.
Ja, es ist schon
interessant. Ja, überhaupt diese ganze Type-Hinting-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 es dann einen Fehler gemacht habe.
Kann Wim das auch?
Kann Wim das auch, gutes Linting?
Ich weiß es gar nicht.
Ich habe das nie wirklich verwendet, glaube ich.
Also irgendwer aus dem Off-Drive bestimmt ja.
Das geht bestimmt, ja. Ich habe das jetzt aber gar nicht
da drin 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 Projektmeta oder Package-Metadaten
kann man halt super viele praktische
Sachen mitgeben und da die Piper-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
dann sagst, hey, hier, das ist die aktuelle Piper-Version
oder der Bild läuft durch oder meine Docs funktionieren.
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, es ist einfach aufpeppen die Seite.
Du hast ein bisschen Convenience dazu benutzt.
Genau, Convenience und auch die Leute einfach so ein bisschen
so, hey, guck mal, ich weiß, was ich hier tue.
Ich habe ja 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?
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 PyPy und einfach sucht,
okay, ich möchte jetzt 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 da alles machen kann.
Also gut geklaut ist halb gewonnen.
Ja, ja, auf jeden Fall. Oh, das wollte ich eben noch
sagen, das habe ich dann irgendwie vergessen.
Genau, also Tests, ja.
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 habe ich meistens
sowieso einen Checkout von dem Repository,
dass ich dann in das Paket
selber reingucke.
Nee, eigentlich auch nicht.
Insofern, genau, ich mache das inzwischen
auch so, dass die Tests halt nicht mehr in dem Paket mit drin sind.
Ja, man kann schöne Sachen mit Paketen 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 eigener
Teil wäre halt sowas wie irgendwie, baue ich
ein Binary, einfach
dass ich ein executable Ding
irgendwie bauen kann.
Das hätte man jetzt auch
hier noch machen können, aber
ich bin nicht vorbereitet.
Müssen wir uns das Ganze nochmal angucken, wie das so funktioniert.
Ich habe gerade das Benutzen, Leute. Also ich bin
kein Fan davon persönlich, aber
es nimmt sehr viel Kontrolle,
die ich nicht abgeben möchte, immer ab.
Deswegen muss man es immer so im Zaum halten.
Conner. Achso.
Wieso? Also es ist relativ intrusiv.
Das heißt, man kann es nicht einfach so daneben
den Rest packen. Also ich muss
zum Beispiel, um es mit PyEnv zu benutzen
und 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 System-Conflicts 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
ne, war es nicht.
Fällt mir jetzt auch
nichts mehr ein.
Ja, ich glaube eine Sache, die ist noch ganz cool, also ich habe tatsächlich gemerkt, dass selbst wenn ich Code schreibe, dann bemühe ich mich denen 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 denkt, ach komm, irgendwie du hast so ein Spezial für dein Projekt, ja, das weiß ich nicht, du hast so ein separates User-Model, ja, ist okay, das lasse ich einfach so nachdenken.
Nee, das funktioniert nicht so, das muss man nochmal sauber ziehen und gerade ziehen.
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.
Ja, wollen wir noch Pics machen?
Habt ihr Pics der Woche?
Etwas, ja.
Ja, okay. Dann bitte dann.
Allerdings ist es kein
Paket oder keine Software, sondern
es ist ein Artikel.
Ist aber auch lang.
Habt mal viel Spaß mit.
Aufwand
Subclassing in
Python Redux.
Ich weiß nicht, ob wir den...
Du kannst das doch mal wiederholen, bitte.
Subclassing in Python Redux.
Ja.
Am 20. Juni rausgekommen ist jetzt,
also gefühlt noch gar nicht so lange her, vielleicht eine Woche
oder müsste eigentlich mehr, etwas mehr
als eine Woche vielleicht sogar. Ja, ich glaube eine Woche
und 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 es halt, 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 alles schrecklich.
Ich komme da nicht wieder raus.
Und ja,
das ist auf jeden Fall,
sollte man sich mal die Zeit nehmen,
wenn man so einen langen, dunklen Nachmittag,
jetzt ist gerade Sommer,
Zeit hat, dich das mal durchlesen.
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 hast?
Ich glaube
tatsächlich gerade nicht aus dem
MFF. 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 JungleCon 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 und
ich glaube, dass 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 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
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
und auch irgendwie ein bisschen
was zurückgeben zu können, weil
wir nutzen ja schon Dango irgendwie sehr, sehr viel
Und ja, ansonsten, man kriegt da halt so ein paar Möglichkeiten. Du kannst dann einen Job-Offer im Slack posten, du kriegst einen Kanal, den du dann bearbeiten kannst. Das haben wir tatsächlich gar nicht so wirklich gemacht, weil wir hatten da irgendwie gar nicht so drüber nachgedacht, sage ich mal.
Also, weil es war einfach so, ja klar, wir sind im Slack, unterschreibst du mit den Leuten und haben sich noch ein paar Leute 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, ob das Lautzwurm war oder einer von denen auf jeden Fall,
die hatten auf jeden Fall da richtig viel,
da ging richtig viel rund.
Six Feet Up ist, glaube ich, die Firma, die das
gebaut hat oder so.
Ich wüsste, Six Feet Under.
Und das
ist eigentlich 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 sagt,
hey, ich will euch was verkaufen.
Von daher denke ich mal, also wir haben
ja jetzt schon, das war jetzt die dritte
Con-Folge, die wir gesponsert haben oder die vierte.
Das war mir auch gar nicht klar. Aber wir waren diesmal
ein Sponsortyp höher. Also ich glaube, wir waren jetzt Silber
und davor waren wir immer Bronze.
Aber tatsächlich
glaube ich, würden wir das nächste Mal auch mal
gucken, dass wir da dann auch ein bisschen mehr
das nutzen, die Möglichkeiten, die man da bekommt.
Weil wie gesagt, das ist schon cool und
auch da irgendwie so einen direkten Draht zu den Leuten zu haben
und ja, ich meine klar, wenn du
vor Ort bist, ist eh nochmal alles anders. Da hängt ja jetzt nicht jeder
zwingend am Laptop, aber
das ist schon,
ich denke mal auch, ich tippe mal, dass
dieses Hybrid-Ding wird auch einfach bleiben.
Ja, haben viele Leute gesagt, hm?
Ja, vor allem, ich meine, es ist auch einfach, keine Ahnung,
es waren, glaube ich, 700 Leute oder so im Slack,
habe ich gesehen und normalerweise sind Django-Cons auf 300
irgendwas begrenzt oder 400 oder so.
Super viele 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.
Mhm, ja.
Stimmt, so ein Lohlehrblick.
Ich bin noch nicht so ganz sicher,
ich finde das schon wichtig, diese Inklusion, aber
so live treffen, ich vermisse zum Beispiel
das beim Meetup, beim Django-Meetup, ne?
Ich finde es viel schöner, euch da persönlich zu sehen.
Absolut, also ich würde nicht sagen, dass man das
nur noch macht, aber es wird immer
Leute geben, wie uns drei, die da wirklich
Spaß dran haben, die da gerne irgendwo hingehen,
aber es gibt halt auch Leute, die halt einfach
vollkommen zufrieden sind, das so auch als
so ein Radio-Event oder so was,
oder so ein Fernsehen halt irgendwie nebenher laufen
zu lassen. Manchmal ist es weniger Commitment,
es ist mehr so Leeching
und die Frage ist halt, 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 und das irgendwie, 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 vielleicht. Aber ich glaube also
jetzt bei der Django-Community, glaube ich, gibt es so viele Leute, die
da wirklich Spaß dran haben, die Tickets sind ja auch eigentlich immer
ausverkauft, also die Vorort-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 Dago-Meetup
jetzt
werden wir auch, ich meine, es ist frei,
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 halt Lust hat,
sich irgendwie remote dazu zu schalten, dann machen wir das halt.
Ich weiß auch nicht, ob das gut funktioniert,
ob das irgendwie doof ist, ob dann vielleicht alle Leute eh sagen,
boah, geil, vor Ort Bier trinken,
keine Ahnung, mit Leuten
reden, sozialisieren,
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
ja, keine Ahnung, wenn jemand in der Eifel oder
sowas, also jetzt hier, ne, Kölner Raum,
Eifel ist ja irgendwie so.
Janz weit draußen.
Ist dann halt teilweise vor allem abends ziemlich schwierig, hin und zurück zu kommen,
wenn du irgendwie nicht extra ein Auto fährst oder so
und einfach die Leute dann auch mitnehmen,
mitzunehmen, wenn die da Spaß dran haben,
das fände ich schon gut, das möglich zu machen.
Wie 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 Meetup
hast du erzählt. Ja genau, ich
bin vom Philipp, der ist jetzt seit Januar
der Organisator davon, angeschrieben worden
über LinkedIn, hat 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 DjangoCon.
Okay.
Zum Besten gegeben.
Zum Besten gegeben, genau.
Ich dachte, du hättest über Packages geredet, schade.
Nein.
Und ja, 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 dann gesagt,
dass das bei mir persönlich vorbeigegangen ist.
Aber 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
ansatzweise mit diesen
Sachen arbeiten müssen und mehr
als irgendwie mal mit der Django Shell mal kurz ein Model
irgendwie aus der Datenbank holen, habe ich halt noch nicht gemacht,
so ungefähr, ja. Und dann irgendwie zu sagen, ich will
da irgendwie ein Betriebssystem drauf installieren oder sowas,
es war einfach sehr weit
weg. Was nicht heißt, dass der Talk
schlecht war oder sowas, das hat mich halt als 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 die nächste Woche mal online stellen, die
Talks. Ich weiß gar nicht, ob das schon gemacht wird.
Ich glaube, ein Monat, das müsste ja genau dieses
Wochenende sein. Wann war die JungleCon?
2. Juni oder so? 2. bis 6. Juni, ja.
Genau, und das haben wir ja. Ja, morgen ist es
weiter. Also, genau, mal gucken.
Ich werde das auf jeden Fall dann auch noch in die
Shownotes packen, wenn sich das
geben sollte. Sehr interessant.
Ach so, ich habe auch noch einen Pick der Woche. Ja.
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 Mand, ne? Linux-Command,
um sich die Mand-Pages anzugucken
von einem Command. 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 Main, das heißt,
gibst TLDR und Command-Name ein und es zeigt dir nicht
die Main-Pages an, sondern die häufigsten
vier oder fünf Use-Cases, wie man
das Ding benutzt. Ah, okay, ja, 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 Main-Pages gucken, wie war das und
was heißt denn der Parameter? Nee, du siehst halt direkt
irgendwie, wie ging das jetzt noch mal
mit dem Grab oder mit dem Find und dann weißt du
direkt, ah, so benutzt man das, ah, total super und
cool. Richtig on 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.
Ah, okay.
Muss man vielleicht auch unbedingt nicht schon los.
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.
Okay, doch, das habe ich, genau, Watt, XR, ja, ja.
Genau, genau, da ist auch TLDR dabei.
Und viele, also tolle
Implementierung auch in Rust und so, aber das ist
ja, sehr nice, wenn man modernen Linux
mag, Eudonics mag und
ja, der TLDR ist auch auf PiPi tatsächlich und
kann sich einfach
an die Stelle ziehen und macht Spaß.
Ja, sehr cool. Wunderbar. Muss ich auch mal angucken.
Vorrangig.
Ja, ich glaube, wir sind am Ende für diese Folge.
Wir finden, dass du wieder da warst, Ronny.
Vielen Dank, dass ich dir Spaß gemacht habe.
Viel Spaß gemacht, ja.
Ja, und ich würde euch
sagen, hört uns, wann ihr uns hören wollt.
Bleibt uns gewogen. Morgens, mittags, abends,
nachts beim Fahrradfahren.
Pass trotzdem ein bisschen auf und bleib gesund.
Und ja, bis zum nächsten Mal.
Ja, alles klar.
Tschüss.
Tschüss, ciao.