Transkript: Python Packaging

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast.

In der 34.

Episode heute.

Ja, wir nehmen wieder Abend auf, ausnahmsweise.

Muss ja auch mal sein.

Schön, dass ihr wieder eingeschaltet habt.

Was machen wir heute?

Wir wollten ein bisschen was über Pakete besprechen.

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

Hi Jochen.

Und der Gast ist heute wieder Ronny.

Hi Ronny.

Hi.

Hallo.

Ich bin der Dominik.

Ja.

Ja.

Ja, weiß nicht, ob wir wieder Stutu machen wollten.

Ein bisschen News oder so.

Habt ihr News?

Nee, ich habe leider, ich bin zu irgendwie nicht viel gekommen und habe auch keine Newsletter oder sonst irgendwas gelesen.

Daher hat auch viel.

Also es kam tatsächlich der Co-Pilot auf GitHub heute raus zum Coden.

Das fand ich ja ganz interessant.

Das ist jetzt keine Python-News, aber.

Okay.

Ja, also man kann sich da anmelden, irgendwie eintragen in so einer Test-Dar-Liste.

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

Was macht das denn?

Das ist ein Co-Pilot für GitHub, der, wenn man Doc-String schreibt, automatisch die Funktionen baut, der für verschiedene Sprachen funktioniert.

Sieht ziemlich nice aus.

Also so die Demo, wenn das mal richtig gut funktioniert, irgendwie mit Machine Learning dahinter wahrscheinlich so ein bisschen.

Bleibt einfach einen coolen Doc-String.

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

Ja, ich hab das irgendwie, ich habe nur so einen Animated GIF auf Twitter oder so gesehen, wo da jemand mit Cycited Learn was gemacht hat.

Und das sah schon 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 tun.

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ätzlich Konzepte da sehr schnell mit lernen kann.

Das ist auch so interessant.

Außerdem wird man gezwungen, Dokumentation zu schreiben.

Direkt.

Am Anfang, das ist vielleicht auch gar nicht so doof.

Also ist halt die Frage, wohin das hinterher, 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ßt du.

Ja, das ist die durchschnittliche GitHub-Code-Qualität.

Ich meine, wenn das jetzt, also kann ja noch Verbesserung sein.

Ja, genau.

Also ich finde es wirklich interessant und es sah auch echt top aus.

Documentation-driven Development.

Irgendwie so.

Specification-driven Development.

Ja, also diese Beispiele auf der Seite vom Co-Piloten da, die sahen echt schick aus, auch in Python-Deistag, ja.

Okay, ja, cool.

Das ist auf jeden Fall eine Neuigkeit, ja.

Ja, haben wir noch was?

Ich glaube, was war hast du gesagt?

Python 306, ja, egal.

Ja, ist vor drei Tagen oder so rausgekommen.

Aber ich weiß ehrlich gesagt nicht mehr, was der Unterschied ist.

Welche Bugs sind gekriegt worden?

Voll gut.

Nur so eine Erinnerung, dass man das jetzt mal dann installieren könnte.

Aber ansonsten.

Ist groß passiert.

Also dann würden wir doch direkt davor gekommen oder fällt dir noch was ein, Ronny?

Ist doch eigentlich eine gute Überleitung.

So GitHub-Packages.

Stimmt.

Package.

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 wieder benutzen 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 sagen wir so, es gibt unterschiedliche Arten von Paketen.

Das ist vielleicht ja schon mal so ein grundsätzliches Ding, mit dem man anfangen kann.

Also es gibt halt zum Beispiel, also oder weiß nicht, wo wollen wir damit anfangen oder mit der Geschichte von

der Geschichte.

Packaging.

Ja, okay, ich bin gespannt.

Ich hätte gesagt, es gibt doch DCP-IP, aber Entschuldigung, klar.

Ja.

Da gibt es auch Pakete, ja.

Vielleicht nur so ganz kurz, es ist halt leider verwirrend, das ist kompliziert und das ist komisch und das 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 gibt 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 das komplette Repository zu halten.

Ja, oder vielleicht wenn

es so ein bisschen Repository nichts zu Python hat oder so.

Oder der weiß man 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 will ich ganz kurz noch, wenn wir jetzt schon mal wieder bei Python-Progressen noch ein bisschen einsteigen, was ist denn Dis-Util?

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.

Achso, ja, ach das.

Also S-Dist ist halt Source-Distribution und sagt eigentlich im Grunde, dass man halt nur den Code irgendwie ins Paket packt, also den Source ins Paket packt und dann halt auf ein Zielsystem halt eventuell noch, wenn da Extensions, zum Beispiel C-Extensions oder so drin sind, muss man die da dann halt noch bauen.

Also es ist halt noch nicht gebaut, und die sind nicht die PYC-Files, sondern es sind nur die, die tatsächlich die Dot-PY-Files.

Und weil die PYC-Files, die hängen natürlich, das hängt auch vom Interpreterversion ab und so.

Also und dann gibt es halt die B-DIS, also die Build-Distribution-Pakete, genau.

Und das sind halt irgendwie Tarballs vor allen Dingen gewesen oder manchmal auf Windows, glaube ich, auf 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 Nuller Jahre, keine Ahnung mal 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 Zipfall war.

Und inzwischen sind es Wheels, das ist auch mehr oder weniger ein Zipfall.

Aber so ein bisschen sind 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 rumgefockt worden ist und dann sind Dinge auch wieder zurück nach Setup-Tools gegangen.

Und Setup-Tools ist aber nie Teil der Standardbibliothek geworden.

Dist-Utils war es dann aber auch schon immer schon lange.

Sodass heute ist es halt so, es gibt halt Dinge, die macht Dist-Utils, 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 Stadt-Bibliothek, 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.

Ja, okay.

Das klingt aber so, als geht das halt nicht out of the box.

Und da braucht man schon noch andere Sachen.

Also ohne C-Compiler geht das wahrscheinlich dann nicht irgendwie oder so.

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 kompiliert werden muss, dann braucht man halt irgendwie so einen 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 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 SSH-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 PyPy stellen und.

Das wäre aber heute der Level, aber nicht nur die Wheels, sondern auch Source Distribution und Build-Distributions kann man auch auf PyPI stellen.

Und passiert auch oft.

Und oft muss man es dann auch selber kompilieren, noch, wenn es halt keine Wheels gibt zum Beispiel.

Was mir eben, ich habe jetzt auch hier so ein M1 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 Python6 irgendwie, weil es dann noch 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 10.

Ja, und dann und einem zur Verzweiflung treibt, wenn irgendwelche Details in dieser Compile-Pipeline und irgendwann, wenn der Vortrag-Ciler nicht richtig ist oder keine Ahnung, irgendwas bei der Emulation von des Intel-Prozessors nicht richtig funktioniert oder so, dann kriegt man eine sehr, sehr komische Fehlermeldung aus den Tiefen von irgendwelchen Compiler-Toolchains.

Ja, okay.

Ja, also tatsächlich auf anderen Systemen bauen zu wollen, ist dann, und auf einer neuen Versionen ist dann vielleicht immer nicht ganz einfach.

Aber das Gute ist, dass man tatsächlich auch, wenn man jetzt, vor allem wenn man jetzt mal anfängt, dass man ja dann doch eher in der reinen Python-Welt bleibt und dass man dann das auch relativ entspannt einfach ohne irgendwelche großen Probleme die Packages erstens bauen kann und zweitens dann auch die dann auch wieder leicht installieren kann.

Also man kann sich relativ viel von diesem Komplexitäts-Overhead sparen, indem man quasi keine externen Libraries verwendet, irgendwie sowas, ja.

Genau, ja.

Also reines Python ist eigentlich relativ einfach dann, ja.

Also das Einzige, was halt dann mit in den in den Build-Distributions drin ist, sind halt die PYC-Files und PYC.

Ah ja.

Also ansonsten muss die halt noch einmal von PY nach PYC verwandeln, aber das ist auch alles, das merkt man heutzutage gar nicht mehr.

Sag ich mal.

Und dann hat man so ein Paket und dann hat man das auf Pipe und dann kann jeder das laden.

Über PIP oder sowas mit Genau-Style oder ja.

Ja, und die ganze Dokumentation dazu, ich hab mich ehrlich gesagt nicht wirklich vorbereitet, aber ich habe einmal geguckt, was gibt es denn an?

Habe ich irgendwelche Bücher zufällig, wo was drinsteht über Packaging?

Und da gab es irgendwie ein Buch Python Expert Programming, da war ein bisschen was drin, ein Kapitel.

Und ansonsten ja, hier klingeln Dinge.

Das ist immer sowas, ne?

Telefon auf Flugmodus stellen.

Das ist ja mal eine Checkliste machen.

Oh ja, das ist lang her.

Was ist denn 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 da das letzte Mal auch schon von Documentation.divo.com.

Sozusagen, also es gibt auch einen schönen Vortrag eben von Daniele Pushida über der schon wieder, genau, wie schreibt man eigentlich Dokumentationen sinnvollerweise und der teilt das halt auf in, naja, so, man sollte, es gibt halt unterschiedliche Quadranten und unterschiedliche Zielrichtungen, ne?

Und man, und dann schreibt man halt Tutorials, How-to-Guides, Explanations oder Reference Documentation.

Und das kann ich.

Er hat mit dem Vortrag Programming for Pleasure gemacht.

Genau, das war dieses Jahr, das war, glaube ich, hier, wo wir die Dokumentation einen Vortrag gemacht, da war 2017 oder so.

Kann man sich auch angucken, sehr, habe ich letztes Mal, haben wir letztes Mal schon verlinkt in der JugoCon Europe-Episode, sehr empfehlenswert.

Und was ich halt gesehen habe, ist, dass sich Pipe A hält sich genau da dran.

Da sieht man halt, genau, sie machen Tutorials, dann machen sie How-Toguides 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, meine Dokumentation ist ja im TT.

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 jemand anders hast, der es vielleicht liest, dann auch noch mit.

Nein, machen kannst du selber in einem halben Jahr und freut sich vor.

Genau, ja.

Ja.

Das ist immer ganz nett, weil dann, äh, dann, man ist schneller beim zweiten Mal, wenn man halt einfach seine eigenen Doku lesen kann und sich nicht immer komplett von neuem irgendwo einarbeiten muss.

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

Ich habe mir mal irgendwo mal abgeguckt, dass wenn man, sag ich mal, eine Methode hat, die vielleicht 20, 30 Zeilen irgendwie relativ viel macht, also du hast ein If und eine Schleif 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 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 Docstring drüber schreibt, welche der liest dich irgendwie.

Man ist ja irgendwie so ein bisschen faul.

Ja, aber das ist eigentlich gar nicht das Thema.

Ja, weil ich das nicht so gut habe.

Ja, also wobei, ich weiß nicht, weil bei Dokumentation innerhalb von Source Code ist es natürlich, oder Kommentare in Source Code finde ich immer ein bisschen schwierig.

Also es kommt drauf an, was es ist, gibt 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, oder?

Also warum man so bestimmte Sachen macht, die irgendwie komisch aussehen, dass das vielleicht manchmal gar nicht so schlecht wirkt.

Nee, das durchaus sinnvoll, aber ja, von, na, wie heißt er noch?

Dingstar.

Clean Code, Ankel Bob.

Der sagt immer, das Erste, was er macht, wenn du durch Code redest, 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, und also jetzt ein Extern sich, dass ich und ich überlege, ob ich das nutzen möchte und vielleicht auch produktiv nutzen möchte und da ist halt gar nichts dokumentiert, dann habe ich direkt schon mal so ein großes Fragezeichen im Kopf, ob ich das wirklich nutzen möchte.

Wenn das

gut strukturiert, ist, gut dokumentiert ist, dass das lesbarer Code ist, vernünftig aufgeräumt ist, das macht schon echt viel aus.

Ja.

Moderner Stil.

Wir haben ja alles einen gewissen Taste mittlerweile.

Ja, aber wir wollten gerade bei, wir sind gerade bei Dokumentation gelernt, aber wir sind ja über Packaging da hingekommen.

Und ja, also okay, wir haben jetzt gesagt, okay, Setup-Tools, Disutils, 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 einem 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 macht.

Ah, Moment, aha, man braucht Metadaten zu einem Paket natürlich.

Ja, ja, also zum Beispiel sowas Simples wie, wie soll das Paket heißen?

Das ist halt, 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 den Paket selber oder solche Sachen.

Aber auf der anderen Seite macht das halt, dass der Infrastruktur drunter sehr, sehr schwer, dass das so dynamisch ist.

Und bei Product Home ist das ja auch ähnlich, ne?

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 Docswing 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 unten drunter funktioniert.

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, 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 PY ist für uns ein Riesenproblem eigentlich.

Also ich glaube, Setup Chief G ist viel davon ist auch in Py-Project Hummel dann gewandert.

Genau, also Pipe Project Hummel ist mehr oder weniger ein neues Format dafür, ja.

Und das ist halt die aktuellste Art, wie man die Metadaten sozusagen erfasst.

Und das ist halt auch Standard.

Ich glaube, das ist PEP 518 oder sowas irgendwie, glaube ich.

Ja, also das wandert jetzt alles in Pipe Project Hummel rein und dann kann man das mit, und 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 ja, Poetry gibt es, es gibt aber auch, ich glaube, das ist, habe ich letztens in letzter Zeit viel Gutes drüber gehört, ist Flit.

Aha.

Ja.

Oh, Flit.

Es liest halt auch Py-Project Hommel aus und baut halt Pakete.

Und vor allen Dingen benutzt das halt nicht, glaube ich, nicht Setup-Tools, sondern macht das alles selber.

Und es benutzt auch nicht Fine, um dann hinterher die Pakete hochzuladen, sondern macht das auch selber.

Also es ist halt so eine komplett integrierte Geschichte.

Was heißt Flit?

Das ist Coli, also das Symbol ist ein Kolibri.

Ich fragte mich, ob das auf Flit tut.

Ich weiß jetzt nicht, wo der Name herkommt.

Keine Ahnung.

Also ein einfaches Modul, um Packages auf PiPy zu bekommen.

Kenne ich auch noch nicht.

Klingt spannend.

Ja, ich habe es jetzt letztens davon gehört, also ich hatte schon mal vorher davon gehört, aber jetzt mal ausführlicher in einem Podcast-Episode irgendwie Talk Python to me, wo, äh, nicht, nee, nicht Talk Python to me, haha, falsch.

Test <unk> Code, glaube ich.

Brian Ocken, der hatte da Brad Cannon zu Gast und der halt irgendwie da halt auch für diese Pi PA irgendwie wesentlich zuständig ist.

Und ja, der sagte also, er benutzt auch selber Flit und das würde ihm sehr gut gefallen, weil es halt einfach schnell und so und macht das, was es soll.

Während Poetry.

Ich verwende ja Poetry normalerweise, aber ehrlich gesagt, so manchmal, ich hätte das jetzt auch, ich glaube, in dem Stream, wo ich da so Live-Sachen gerade irgendwie entwickelte, da habe ich dann irgendwann mal das Virtual End Facts schmeißen müssen und dann habe ich ja nochmal alles irgendwie neu neu von Pipei gezogen und Poetry 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, dass das Async macht.

Ja, mir geht das an einzelnen Stein auf den Nerd.

Da ist irgendwas richtig kaputt, weil das darf nicht, also das kann, ich kann mir nicht vorstellen, wie das irgendwie, welchen Grund es dafür geben könnte.

Also ich meine, weiß nicht, wie viel, also 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?

Dass es irgendwie irgendwas ist da.

Oder es braucht es halt irgendwie, wenn es ein Netzwerk macht, das kann natürlich auch sein und ein PyPI überlastet ist oder so, vielleicht würde PIP auch so lange brauchen, aber Poetry bringt ja einen eigenen Resolver mit und macht das halt nicht über PIP.

Aber offenbar ist das irgendwie nicht so ganz okay.

Also Poetry hat mir schon so ein paar Mal irgendwie tatsächlich echt, ich dachte so, okay, da ist irgendwas nicht in Ordnung.

Insofern.

Also, falls

ich schon immer mal Open Source entwickeln wollte, der scheint so, es gibt ja ein paar Pull-Requests, die notwendig sind.

Keine Ahnung, vielleicht muss ich mal reingucken, was da los ist, aber irgendwas, also das, da kriege ich auf jeden Fall, wenn ich sowas sehe, kriege ich einen Schreck.

Weil das bin ich ja so, oh, das ist ein Tool, auf das ich mich verlasse und das macht komische Dinge.

Und das hat man auch so, also was mich auch bei Poetry so ein bisschen, wo ich auch dachte, ach, das ist nicht so schlimm, aber das hat dann doch auch immer wieder Probleme, ist halt, dass man, dass da halt, das gibt es bei den Setup-Tools, ähm, gibt es Setup, man kann Python-Setup-PY-Develop ausführen oder halt Pip-I und damit halt so eine editierbare Version von dem 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.

Was meinst du mit editierbarer Version installieren?

Also da lädt quasi seine lokale Datei als SIM-Link.

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 ein neues Paket installieren, sondern es ist halt dann die geänderte Version vom Code ist dann halt direkt da.

Das ist tatsächlich ein ganz, ganz wichtiger Punkt, den ich auch lernen musste.

Wenn man mit dem Package arbeitet, dann denkt man erstmal, ja cool, ne?

Du hast ja meist den Code irgendwo oder oft fängt man ja anders an und denkt, ah, ich habe jetzt was gebaut in meinem Projekt, ich würde das gerne irgendwie generalisieren oder vielleicht andere Leute 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 ein eigenes Projekt, ist ja jetzt nicht standalone, ist ja kein Django-Projekt in meiner Welt.

Was macht man denn dann?

Dieses Pip-E, das ist tatsächlich sehr, sehr cool und sehr einfach.

Also ich nutze in den meisten Projekten Pip-Env, einfach weil, ja, weil.

Ich hab gehört, Poetry sei besser, keine Ahnung.

Nö, weiß ich nicht.

Naja, auf jeden Fall, ich bügele das dann halt einfach dann nochmal, also alles mit Pip-Env installiert und so und dann einfach manuell nochmal mit Pip dann das drüber bügeln, um diesen SIM-Link zu machen.

Und damit kann man dann sehr, sehr entspannt und sehr cool, dann auch mit zwei verschiedenen IDEs einfach.

Im einen ändert man halt dann das Package, was man gerade, oder den Source-Code des Packages, im anderen hast du quasi deinen richtigen Django-Web-Server oder was auch immer das 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, das hast du auch bei GitHub hochgestellt.

Genau, ja.

Ich habe vor ein paar Jahren die Ownership von einem Package über 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 von Projekt zu Projekt kopieren, ist doof.

Und da so ja, machen wir mal ein Package und dann ist es halt einfacher zu installieren.

So, dann hat man auch ein bisschen, wenn man mal einen Bug gefixt hat, dann 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 dafür.

Genau, ohne dass man es halt kopieren muss und hat halt dann keine Code-Redundanzen und sowas.

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

Ja, vor allem, das ist halt blöd, wenn man halt irgendwas weiterentwickelt, ein neues Feature.

Und dann muss das in jedem einzelnen Projekt wieder nachbauen, das ist ja natürlich.

Genau, das ist sehr mühsam.

Genau, und dann haben wir uns dann, dann ist da halt über Jahre dann so einbahnstraßenmäßig da halt Code hineingeflossen.

Auch dann irgendwie gab es dann über 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 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, 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 angefangen zu gucken, was ist denn da eigentlich alles drin?

Und wie gesagt, da waren dann Kompatibilitätsprobleme.

Und dann war anfangs noch kein Linting drin und die Dokumentation, es war nichts dokumentiert.

Es gab keine Doc-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 den Code rumgesucht, aber es 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 immer 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 da, 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 Changelog macht.

Allein schon für einen selbst.

Ich habe keine Ahnung, was ich vor.

Also ich mach ungefähr alle ein bis zwei Monate ein Release.

Also entweder irgendeine Art von Release.

Kann mal Mage-Release sein, wenn ich irgendwas Größeres wirklich rudimentär gemacht habe oder halt irgendwas Kleineres, aber so ein bis alle 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 möchte 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, ist echt blöd.

Aber das geht ja dann auch direkt Richtung, wie vergibt man Versionsnummern und was ist, da gibt es ja ein bisschen.

Ja, genau, da sind wir ja, genau.

Semantic Versioning, glaube ich, habe ich gehört, dass da en vogue.

Macht man das noch?

Ja, naja, nicht, also ich halt.

Wie man lustig ist.

Ich guck mal, äh.

SEM-Serverorg.

Ich hab grad einen muss gerade einen Artikel, der Semantic Versioning won't save you.

Ja, also es kann ja zum Beispiel sein, dass man eine neue Major Version rausbringt, so von 2 auf 3 oder sowas, dann gehen Dinge kaputt.

Das sind man ja vielleicht nicht.

Ja, also genau, da gibt es einen sehr schönen Blogartikel von Hüneck, Heinek, Schlawak, Semantic Versioning will not save you.

Der ist auch jetzt, also genau, der ist von Anfang März, denn an den habe ich mich erinnert.

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

Vielleicht, was ist das denn?

Was ist denn Semantic 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 mit einer 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 Tubels verwendet, damit es klar ist, welche, und dann wird es halt, dann oft hat man dann halt irgendwie Major-Version Punkt Minor, Punkt irgendwie Patchrelease oder so.

Und in den Patchreleases 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 dann.

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, als größer gleich dieser Miner-Version zum Beispiel, sodass halt sie kleinere Updates oder auch Features noch bekommen oder halt alle Security-Patches, aber halt nicht, dass die Kompatibilität nicht gebrochen wird.

Nur das Problem ist natürlich, dass tatsächlich garantiert das halt auch ein Bugfix kann natürlich die Kompatibilität berechnen, 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

0929, 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 wir, glaube ich, von, weiß ich, 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 einen F-String ohne Variablen hast, dann ist es auch rausgeflogen.

Und plötzlich sind halt dann bei diversen Projekten geht die Pipeline nicht mehr.

Also, ich habe da nichts geändert, was ist denn jetzt los?

War halt mit einem Star-Import einfach im Pip-File und ja, blöd.

Tja.

Genau.

Wie gesagt, vielleicht war das, hätte das schon vorher ü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 deinem Pipeline, aber trotzdem.

Ja, das hat dafür ist dann Poultry wieder ganz cool, 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 irgendwie Pakete irgendwo hinzulegen, ist ja auch so etwas, was dann, was dann zumindest überprüft wird, dass er stimmt und so.

Er würde dich auch nicht davor retten, wenn da schon ein maliches 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 Salary, 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, also ich habe gerade ein Problem mit einer 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, sie 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 Topf wegschmeißen.

Toll.

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

Dass dann halt das Dependency-Resolving vernünftig funktioniert, aber naja.

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

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

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

Also wie baut man denn jetzt Python so zusammen, dass es immer vernünftig funktioniert, immer wieder auch in zwei Jahren noch irgendwo und das ist ein bisschen blöd irgendwie.

Also auch wenn man jetzt, ich nehme jetzt mal dieses Windows-Beispiel, wenn man jetzt da 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 Websoftware.

Das ist ja genau der Grund, dass man diesen Knatsch halt nicht mehr hat.

Ja gut, aber es gibt ja auch da verschiedenste Lösungen, wie man irgendwie so ein großes Paket 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, Py-Installer ist halt wahrscheinlich vielleicht so die populärste.

Es gab ja einige.

Nutkar PyOxidizer, wir hatten ja auch schon ein paar Mal drüber.

Das sind jetzt inzwischen, wenn ihr mal auf die Tools guckt, das ist PyOxidizer und so, dass schon wieder alles verschwunden aus den Empfehlungen ist.

Hat sich wohl dann Py-Installer ist irgendwie erstaunlich konstant.

Ja, aber es ist, also ich habe es noch nie richtig.

Funktioniert einfach nicht so, wie man will, wenn man zu viele externe Dependencies drin hat.

Das ist da auch nicht schön.

Ja.

Py2X glaube ich.

Ja, kein einfaches Problem, leider.

Ja, aber ja, also was macht man da?

Also Paketbauen, ja, du sagst Web-Anwendung, ja.

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 dann.

Solange es noch keinen noch gibt, ne?

Ja.

Ja.

Aber tja, ja, nee, ich habe auch keine Lösung dafür.

Meine Lösung ist, nicht aufs System unterwegs sein, wo das ein Problem ist.

Gut, aber es gibt halt Leute, die halt andere Systeme nutzen, das ist ja klar.

Und wenn die darauf lyihen, wenn man von bestimmten Konzernen, die halt dann bestimmte Policies haben, die man nicht verstehen muss, aber wo man sich natürlich daran halten muss.

Die haben bestimmt 1998 Sinn gemacht, dass die jemand eingeführt hat.

Naja, also die sind auch Veränderungsresistent, da würden sich ja ganze Abteilungen sich als Redundant erweisen vielleicht.

Aber wenn die 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, dem Nutzer, den man ja meistens nicht kennt, so ein bisschen 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 mit ziemlich viel Kopfzerbrechen verbunden sein, irgendwas überhaupt hochzuziehen.

Und bei dem habe ich jetzt halt gesagt, hey, wir machen ein Semantic Versioning und da versuche ich mich auch sehr dran zu halten.

Also darum habe ich jetzt auch schon in den Lehren jetzt vier Major Releases gemacht, weil Python halt irgendwie komplett alles auf drei umgestellt, ist halt ein Breaking Change, ne?

Muss halt hochgehen, da kommt es halt nicht drum rum.

Fühlt sich manchmal so ein bisschen verschwenderisch an, wenn man denkt, schon wieder, das ist nicht so viel Code, aber ja, ne?

Und man kann halt einfach nur hoffen, dass man es den Leuten halt möglichst einfach macht, weil das Problem ist, da sitzt dann nachher am anderen Ende der Welt jemand, der möchte genau das Package verwenden oder nutzt es im schlimmsten Fall vielleicht schon.

Und da macht man ihm plötzlich was kaputt, der hat keine Chance halt, irgendwie vernünftig zu erreichen.

Zumindest nicht direkt.

Und da soll man ja schon, sollte man schon gucken, dass man das 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 geschwurbel, um es muss backwards-kompatibel sein für bis in alle Zeiten.

Absolut.

Ich finde es vollkommen okay zu sagen, das Ding geht es 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 Versionsrum 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 keinen Changelog oder so ein ganz rudimentäres.

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

Wie machst du das Changelog und wie schreibst du das dann auch?

Schreibst du dann vor jedem Commit oder lässt du aus den Commit-Messages automatisch dann locken?

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 Changelogger.

Es ist einfach ein Markdown-File.

Deine Arbeit zu dokumentieren.

Ja, also 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 also ich habe einfach einen Markdown-File und da ist halt, das ist halt eine lange Liste, wo dann halt drin steht, hey, am Sohn zu fehlten, habe ich diese Version released und das hat sich geändert.

Ich habe da irgendwie, weiß ich, drei rechtschreibe Fehler, eine 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 obendrin 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.

Ja.

Das ist auf jeden Fall ordentlich, ja.

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, wann ich mit sowas anfangen würde, weil ich würde ja zum Beispiel in der ursprünglichen Entwicklung jetzt damit noch nicht anfangen, Change Talk zu schreiben, wenn ich halt noch nichts habe, was richtig fertig ist und was funktioniert.

Wahrscheinlich so ein 1-0 würde ich auch.

Irgendwie so, ne?

Oder sobald halt Leute anfangen, das zu verwenden.

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

Ja, sobald du was einigermaßen Nutzbares irgendwie hast, vielleicht.

Ja.

Ja, ja.

Ich mache das, ja, ich überlege gerade, ob ich weiß, was ich so mache und dann denke mir so, oh nein, ich breche drauf und die kommt bei die Juliette.

Ich meine, es kommt auch immer darauf an, wenn das halt so ein Mini-Ding ist, also gut, selbst das kann irgendwie an der zentralen 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, so ein, sagt, hey, hier ist so ein Haufen von Zeug, dass du so querbet in deinem Projekt einsetzen kannst.

Der Werkzeugkoffer bei euch im Schrank, ne?

Da hängt auch alle möglichen Schraubenschlüssel rum.

Jeder hat sein eigenen Werkzeugkoffer mit eigenen Schraubenschü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 jetzt nicht auf JavaScript-Level gehen, wo die quasi jeder zwei Zeit ein eigenes Package ist.

Das ist manchmal ein bisschen krass.

Aber wenn man die Sachen vielleicht doch ein bisschen, also sagt man so, würde ich jetzt das Package nicht geerbt haben, sondern würde ich es jetzt neu machen.

Da würde man sagen, hier dieser Code, der soll irgendwie Packages, würde ich sie wahrscheinlich nach gewissen Use Cases strukturieren.

Da auch nicht mehr Core nennen, sondern tatsächlich den Funktional.

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 das ist ganz, ganz typisch.

Aber wie gesagt, also zum Beispiel, ich habe irgendwie ganz viele Sachen gebaut, die mir bei Unitests helfen.

Dann würde ich sagen, hey, das ist dann jetzt kein das Ambient-Unit-Test-Paket oder so.

Und sondern 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 ist dann auch, hat dann auch gewisse Dependencies, die man ja sonst nicht reinholen muss.

Das ist dann auch nur das ein eigenes Paket.

Und ich habe das jetzt mit Extensions tatsächlich tatsächlich gemacht, weil am Anfang war es auch so, dass auch die ganzen Dev-Dependencies wurden alle mitinstalliert immer, weil damals mir gar nicht so bewusst war, dass man das irgendwie trennen kann.

Ich habe das halt einfach immer nur übernommen und so ein bisschen umstrukturiert und dachte, okay, cool, funktioniert, wird schon passen.

Aber man kann halt tatsächlich sagen, dass man verschiedene Extensions macht.

Also das kennt man, wenn man das aus dem Requirements oder so ist, so eine eckige Klammer, wo dann irgendwie, kann bei Salary kann man es mit SQS oder mit Revit oder keine Ahnung, welchen Extensions installieren.

Und da kann man natürlich auch sehr schön dann die Dependencies wegkapssen, 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, so eine 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 stehst du dokumentiert und sagt, hey Leute, das ist das Standardpaket, das ist so, ne, das normale Shit, den man so mit Django machen kann.

Und wenn ihr jetzt irgendwas spezielles U-Layer haben wollt, das ist hier dokumentiert und da müsst ihr halt noch die Extension mit installieren, dann kriegen die halt auch die Dependencies.

Ja, das ist halt auch die Frage, ne?

Bietet man den Leuten direkt das volle Rundum Sorbuspaket an, dass sie ja nicht so viel Aufwand haben und das alles lesen müssen und alles nachinstallieren müssen oder macht man das halt sehr modular?

Also ich sag mal so, 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 meinem 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 zum, 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 hatte, reingeguckt.

Das ist Django File Response.

Oh, da hast du auch in deinem Stream einiges dran gearbeitet.

Genau, da habe ich jetzt bis letzte Woche da noch was angemacht.

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 er die ganze Zeit uns anstellt und wie man dann so entwickelt, wie man das Live macht.

Ja.

Ich finde es eigentlich, das sieht cool aus.

Genau.

Ja, technisch gar nicht so schlecht, glaube ich, inhaltlich, muss ich noch ein bisschen feilen, glaube ich.

Nein, andersrum, ich finde es 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.

Also Pfeilrespons, das fand ich sehr interessant.

Also wo ich tatsächlich noch Schwierigkeiten nicht merke, 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 eine halbe Stunde fertig bin oder so.

Und jetzt kann es sein, dass ich Leute einfach eine halbe Stunde lang fürchterlich langweilen.

Und es ist fruchtlos.

Und dann, also das, das merken normalerweise würde mir das halt nichts ausmachen, mir macht das ja Spaß, mir das zu entwickeln.

Und dann probiere ich halt rum und wenn es halt geht, super, wenn es nicht, geht ja.

Ich muss sagen, also mir macht das dann auch Spaß, weil dieses Rumprobieren, das kriege ich dann ja mit.

Und da lerne ich auch mal was bei.

Und ich glaube, gerade dann, wenn man halt nicht alles so perfekt vorher schon weiß, sondern das so ein bisschen rausknobeln muss.

Und man ist ja quasi mit Live dabei, das ist so ein bisschen vielleicht wie im 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 ich

das auch drauf tun.

Ja, das ist tatsächlich vielleicht eine interessante Geschichte, dass man genau dabei Leuten halt zu gucken.

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 loswerde.

Und da ist mir jetzt schon ein paar Mal aufgefallen, okay, da habe ich dann irgendwas übersprungen oder dann bin ich nicht so, mach ich das nicht so, wie ich das normalerweise machen würde.

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ühren, den kannst du schon später runterscheinen, wo dann einfach so ein Quersensort auf dem Bildschirm steht, so ein schwarzer Balken, dann wird das, was du gerade programmiert hast, einfach kurz sensiert und der Ton geschwemmelt, dann gehst du so selber kurz draufdrücken, dann hast du einen kurzen sensierten Teil, dann kannst du wieder freischalten.

Ja, genau, wird sich schon irgendeine Methode finden.

Kennt ihr das aus Starship Troopers, wo es dann kurz diesen Sensor-Balken gibt und im Hintergrund werden die Kühe dann von den Eltern gegessen und sieht man,

wie so die Darme fliegen, genau.

Ja, das stimmt.

Das ist eine gute Idee.

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

Das ist zwar.

Da habe ich ja dieses Django Fire-Response-Paket gebaut auch.

Da habe ich etwas verwendet, was ich jetzt vielleicht dann, das auch nur aus Spaß, ja, habe ich eine MBDev, was in der Data Science Welt ja so ein bisschen verbreitet hat.

Vielleicht nochmal ganz kurz, das hast du auch schon mal zwar einmal kurz erklärt, aber MBDev ist quasi, entwickeln mit dem Notebook, aber das Notebook quasi das bei dem Paket automatisch mit die Dokumentation 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 extras Require zum Beispiel.

Und kann dann halt, das sind 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-Response-Ding ist halt 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 NB-Dev-Kram mitkommen zum Beispiel.

Ja, genau.

Es würden Jupyter Notebooks mitkommen, es würde Pandas mitkommen, es würde NumPy mitkommen.

Es würde irgendwie so das halbe Data Science-Universum mitkommen.

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

Und dann plötzlich wird dann wahrscheinlich irgendjemand vor einer Konsole sitzen und denkt sich, warum kommt da jetzt ein Fortran-Compiler mit?

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

Ja.

Ja, genau.

Nicht so gut.

Aber vielleicht nochmal kurz für NBDF.

Wie baut man denn quasi sein normales Notebook in ein NBDF um, damit es halt dann auch als Paket nutzbar ist?

Muss ich da quasi ein anderes Notebook nehmen oder kann ich einfach Jupyter Notebook nehmen?

Nee, das ist Jupyter Notebook.

Das Einzige, was man da macht, braucht, ist im Grunde, man muss dieses NBDF installieren und dann halt MBDev-Bild Lib und dann hat man so ein paar Meta-Anweisungen sozusagen für NBDF 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 sagt.

Nee, nicht ist keine Extension, sondern es liest es einfach nur.

Und wenn man da sowas reinschreibt wie Kommentar und dann Export und dann oder Default-Export, dann, 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 schon.

Dann liest du, wird das gelesen.

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

Okay.

Also ich fand's eigentlich ganz nett.

Ich finde das sehr spannend, also sehr cool.

Also ich benutze auch relativ viele Notebooks zum Entwickeln.

Also gerade auch so Django, so I.O.-Sachen oder sowas oder Modell-Sachen, Funktionen, Methoden für, die kann man einfach super schnell dann testen, ne?

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 sich bei euch eingeladen, war schon mal drüber gesprochen.

Ich mache das tatsächlich so, dass ich das oft mit dem Debugger anentwickle.

Ja, das ist auch eine interessante Option, ja, auf jeden Fall.

Das muss ich, habe ich, mache ich nicht so oft, aber das wollte ich mir auf jeden Fall auch nochmal angucken.

Du nutzt ja auch Peitscharm, ne?

Da ist das, glaube ich, sehr komfortabel.

Man muss sich auf jeden Fall abgewöhnen, STRG-S zu drücken.

Ja.

Weil dann speichert die Datei und dann fliegt der Debugger raus.

Aber ich finde das 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, muss ich nur auf die dritte Array-Stelle zugreifen.

Diese Sachen, die man halt, du weißt, es ist da irgendwo und weißt nicht genau, wo es ist.

Und da macht man halt 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, das muss ich auch wieder in die Land brechen.

Das geht auch in anderen Entwicklungsumgebungen tatsächlich ganz gut.

Wenn man die richtig einstellt, ja.

Das haben wir so ein bisschen gefummelt, bis man halt den Debugger halt so laufen hat, wie man das Ganze hätte.

Aber hast du da schon diesen Debugger, den wir letztes Mal vorgestellt haben, gesehen?

Und zwar Kodo, oder wie ist es ja?

Kodo-App?

Kodo, Kolo-App, genau.

Das ist ein neuer Django-Debugger, der relativ coole Sachen machen kann, wie Visualisierung der Code-Pathes und sowas.

Cool, relativ geil, müsste man schauen.

Ist aber nicht verpeiter.

Ja, aber das wäre auch auf jeden Fall, genau, also das habe ich mir auch zum Ziel gesetzt, jetzt, ich meine, normalerweise benutze ich ja immer Wim 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 wie es Code benutzt.

Einfach nur, um das halt auch so ein bisschen zu lernen.

Oder halt auch PyCharm wollte ich auch auf jeden Fall machen.

Ja, also achso, 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 nochmal sehr lehrreich.

Also vielleicht kurz darauf eingehst, wie man jetzt das nachmacht.

Ich würde mir mal vornehmen, das zu versuchen zu verwenden.

Also je mehr man halt neue Sachen das lernt, die man 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 wichtig.

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

Ja, ja, oft.

So was wir programmieren oder sowas, kann ja auch für einige Leute neu sein.

Ich bin jetzt schon fast zu lange dafür, um das 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, zurückblicken von einigen Sachen, die man eigentlich gar nicht wissen wollte.

Aber so da vorne ist immer, der Werk 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, oder was mir heute leichter fällt, oder jetzt sagen wir 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 probier ich halt einfach rum und dann hinterher denke ich so, okay, das war's, aber keine Ahnung, ich weiß gar nicht, ich habe mir ganz 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, so ja, man, wie lange sollte man eigentlich über Probleme nachdenken?

Und die Antwort war eigentlich so, ja, eigentlich gar nicht.

Genau, ja.

Würde ich auch inzwischen sagen, eigentlich lieber dann, wenn man nicht direkt weiterkommt, halt einfach was anderes machen und später nochmal drauf zurückkommt.

Duschen gehen, es fällt einem wie Schuppen vor 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 geben 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 dann inkompatibel, das passiert ja leider immer wieder mal.

Und das ist tatsächlich auch eine Sache, dass wenn man so ein Package in die Welt setzt, ich nehme jetzt mal extra dieses Wort, dass man halt da schon ein bisschen im Kopf halt behalten sollte, wie gehe ich denn damit um mit der Mainership.

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 beim Maintainership, ja.

Nee, wegen wegen Bugs und Problemen.

Ja, gerade wie lange man darüber nachdenken sollte, dass dann 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 vielleicht heute nicht mehr machen, aber ich habe bei 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 der nicht mal mehr das Interesse haben, zu sagen, so, hey, ich schreibe einfach sorry, ich weiß nicht, bin jetzt irgendwie Gärtner und ich mache kein Programmieren mehr, kann ich nicht helfen, sondern es einfach kommt gar nichts mehr.

Obwohl die Leute halt immer noch aktiv sind.

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

Das ist halt immer wieder sehr ärgerlich.

Und ich glaube, dass wenn man so ein Paket in die Welt setzt und man auch irgendwann merkt, okay, ich habe jetzt irgendwie 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, die den Leuten die Feedback geben können.

Also offensichtlich ist es einfach bei GitHub, die Issues.

Die kann man übrigens auch sehr schön über die zum Beispiel Setup Pi oder Project Setup Tommel direkt verlinken in PyPi, dass die Leute direkt über das Changelog und so kann man alles perfekt verlinken, dass die Leute gar nicht lange suchen müssen.

Und dass man dann auf jeden Fall Leuten, die das halt nutzen, die Möglichkeit gibt, dass sie Feedback geben.

Also zum Beispiel, ich habe jetzt 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 der Übersetzungshelper fehlt.

Und das war dann für die Leute halt echt super ärgerlich, weil die halt das irgendwie nutzen wollten.

Wahrscheinlich haben die Blogartikel von mir gelesen, war dann so, ja Mist, in dem Projekt ist alles auf Sprache X und das plötzlich auf Deutsch.

Dann kommt irgendein Unsinn raus.

Genau.

Und das hat mich dann total gefreut.

Also 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.

Das ist halt 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, das ist ja eh schnell gemacht.

Und wie gesagt, das andere mit der Maintainership, 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 auch in der DjangoCon einen schönen Vortrag dazu, wenn das wirklich ein größeres Projekt ist, dass man die da einfach abgeben kann und sagen dann, hey, sorry, ich bin raus hier mit dem Kram, aber das nutzen noch Leute, bitte kümmert euch drum.

Und auf der anderen Seite, dass man natürlich auch dann notfalls auch andere Leute einfach befördern kann und einfach sagen kann, hier, dass das, also ich habe da jetzt irgendwie Interesse, ich muss das reparieren und sagen, 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, ja, da muss man sich halt auch überlegen, will man nicht auch mal was Neues machen oder sowas?

Es ist ja 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 ja so, ich habe auch bei den ganzen Alten, es ist halt einfach nur viele Zeugs inzwischen.

Und ich würde das ja schon gerne alles noch machen.

Ja, es kommen noch nicht gut.

Genau, manchmal möchte man halt auch mal an den Garten gehen oder sowas und in den Karten halt machen.

Nein, nein,

das habe ich jetzt gar nicht gesagt.

Nein, nein, also

das hätte ich eine große Wille dabei.

Aber dass das, was 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, das den Leuten vielleicht kommuniziert, einfach so sorry.

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.

Ja.

Das kann auch sehr overhaming werden.

Also gerade, ich sag mal, das Leben von Leuten ändert sich ja auch oft.

Also so Situationen oder sowas.

Und 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 ist ja auch, hat ja auch Carlton Gibson, glaube ich, macht gefühlt jede zweite Djung-Con einen hervorragenden Vortrag zu dem Thema.

Das ist natürlich ein Problem, aber ich sage, es gibt halt relativ einfache Möglichkeiten, die zwingend natürlich nicht bei jedem zutreffen.

Wenn einer wirklich sagt, hey, ich habe es in den Beruf gewechselt oder ich bin weggezogen oder keine Ahnung was und hab meinen GitHub-Account geschlossen, das war es jetzt für mich.

Okay, kann immer passieren.

Aber ich sage in den meisten Fällen, es ist 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, also ich sag mal, es ist schon schön, wenn man halt so ein paar Issues irgendwie, nicht die größten nicht offen lässt, sondern zumindest ein Team findet, das dann Lust hat, wenn man gerade wirklich viele Leute hat, die dann was benutzen, dass denen halt wenigstens mal deren Pull-Request merge oder denen die Möglichkeit gibt, dass die selber Sachen mergen können.

Also die Interesse dann haben.

Ich meine, klar kann man noch einfach forken und dann irgendwie ein neues Package machen und sowas, aber.

Ja, passiert ja auch oft genug, ja.

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 ja, glaube ich, eine ganz gute Möglichkeit, das zu tun, ja.

Ja, ja, das bin ich jetzt, ah, ja, das hat sich da dem letzten Mal auch was getan, da bin ich jetzt auch mal da beigetreten.

Aha, cool.

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 Jazzband drin sind, reingewendert.

Sozusagen, damit ich die anpassen kann und eigentlich kann ich das ja auch dann einfach so machen vielleicht.

Cool.

Ah, cool.

Dann löst du quasi dein Problem und hilfst aber noch ganz vielen.

Genau.

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.

Das ist vielleicht auch eine kleine Verbesserung immer.

Ja, ja.

Tja, was haben wir denn?

Was haben wir denn, was gibt es denn noch so für Dinge, die wir über Academ irgendwie erzählen sollten?

Habt ihr irgendwie einen, also habt ihr irgendwelche Tools, die ihr bevorzugt verwendet?

Also Flit, okay, kannet ihr jetzt nicht, habe ich auch nicht.

Werde ich ja demnächst mal ausprobieren.

Mal gucken, finde ich das irgendwie voll gut.

Ja, Poetry verwende ich meistens, aber

ja, tatsächlich so zum normalen, lokalen Verwalten schon und zum Bauen.

Du verwendest Pip Env, aber das ist nur für die

Requirements und Logfile.

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 aufkommen ist sie aber eine sehr, sehr angestaubte Setup-Pi.

Setup.

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 Programmcoden.

Aber tatsächlich ist das mit den Wheels sehr, sehr angenehm, weil die Sachen sich einfach alle installieren lassen und man da keinen Knatsch mehr hat.

PiCurl 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 es gesagt hast.

Das werde ich dann hier im 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 Rom 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 Tattoo ist, dann gerne mal ein bisschen nach hinten rutscht.

Ja, ja, auch in diesem Episode mit Brett Cannon, der meint 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 Hauptweg, 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 Set-up-UI-File geschrieben und das kopieren sie halt von Projekt zu Projekt immer weiter.

Das Problem ist halt sozusagen aus Infrastruktursicht dann Abwärtskompatibilität ist halt super wichtig, weil es sind halt oft viele Dinge immer noch im Einsatz, die von irgendwann annu dazu mal mal kopiert worden sind.

Das heißt, man kann die Abwärtskompatibilität nicht mehr brechen, weil ansonsten bricht ganz, ganz viel, ganz, ganz viele Dinge und dessen Vorschlag zu war auch eher Setup CFG zu verwenden und dann halt auch mal, oder irgendein Projekt-Template oder so oder ein Tool, was einem das halt abnimmt.

Das klingt aber auch alles schon wirklich, also ganz dem ganzen Packaging-Ding, ne?

So kurdischer Knoten.

Ja, das ist wirklich gemein.

Ich meine, was will man machen?

Wenn du, wenn 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.

Auf das Wesentliche konzentrieren.

Ja, aber genau, ich habe auch mal einmal so ein Cookie-Cutter-Template verwendet.

Also es gibt ja auch Python Package Cookie-Cutter-Ding-Template von 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.

Natürlich, Honny.

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 Test-Files dann einfach mit in einem Package gebundelt wurden.

Also die Metatests quasi, also die Sachen, die das testen, was ich nach ausliefere.

Mir ist danach aufgefallen, die muss ich ja gar nicht mit ausliefern, weil das interessiert einfach keinen.

Also ich meine, vielleicht siehst du doch, weil die wissen wollen, ob ich vernünftig das abgedeckt habe.

Aber eigentlich liefere ich ja eine Datenmenge aus, die eigentlich nichts mit der eigentlichen Funktionalit zu tun hat.

Und das war für mich so der erste Erkenntnispunkt, sollte mal mal reingucken, wie das damals mal irgendwer 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 Mode, eine Po-Datei nehmen in dem Projekt hatte, die waren natürlich nicht mit eingeschlossen.

Das heißt, ich bandle das Ding wunderbar und dann klappt es halt nicht.

Ich sage, hä, 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 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 und ausschließend hat, aber ja, die kleinen Hürden.

Das ist auch eine der häufigsten Sachen, die wenn man so, oder wie mir passiert, wenn man so GitHub-Action-Pipeline hat, die halt auch testet und so, dass lokal funktioniert alles und dann macht man Push und dann geht die Pipeline kaputt und dann häufig.

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, fast besser als andersrum, weil dann fällt es einem ja direkt auf und dann kann man es einbauen und so.

Das ist wahr.

Dafür sind ja Pipelines dann auch da oder dann die E-Mail, die man bekommt, dass das schon wieder kaputt gegangen ist oder so.

Ja, ja, ja.

Das ist ja ganz praktisch.

Stichwort Pipelines.

Ja.

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, ne?

Ja, die Detox-File, genau.

Und Travis nutzt das dann.

Man kann einstellen, wie viele verschiedene Python-Versionen das einmal durchgehen kann.

Genau, mit welchen Django-Versionen und dann kann man halt relativ simpel in so eine, in so einer Art Yammel-Datei, glaube ich, ist das.

Kann man dann halt eingeben und sagen, okay, ich unterstütze explizit Python 356789C.

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 seinem 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.

Also ich habe immer keine Lust auf Backward-Kompatibility.

Ich weiß nicht, ich will immer die neuen Features drin haben.

Das nutzt aber auch keiner, deswegen ist 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 du, wenn man so Django Admin Extension so sowas baut, da ändert sich ja so schnell mal irgendwas und dass dann dann plötzlich in irgendeine 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 dann 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 Use Case, den man halt im normalen Besser gleich 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, ne?

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.

Okay.

Und dann kann ich ja daraus dann bestimmte Dinge machen.

Also ich könnte zum Beispiel direkt Issues erzeugen aus To-Dos oder aus Issues oder FixMees, 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 doch 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 halt noch was zu tun?

Oder halt zu warten, wenn jemand anders kann, halt direkt sehen, oh ja, da ist jetzt noch das FixMe 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 Pipeline sprach, Pipelines sind eigentlich die Hölle, bis man irgendwie auf Produktionsumgebung da kommen kann, wenn man einigermaßen komplexe Infrastruktur dann irgendwann da hat und bauen muss.

Und also ich habe da YAML-Hölle im Moment von, weiß ich nicht, mehreren YAML-Files, 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 Version.

Ich habe auch Semantic Versioning eingebaut und ich wollte halt einfach die Version bekommen.

Und da der Punkt, wo ich die Versionsnummer pinne, meine Pipotect-Hummel war oder ist, habe ich mir gedacht, okay, ich passe die einfach und benutze ihn weiter.

Dann habe ich meine Version geändert von 099 auf 0.910, weil es ging immer noch nicht weiter.

Und bum.

Jetzt wäre eine Pipeline auseinandergefunden, weil ich einfach den Rec-Ex falsch gepasst hatte.

Solche Kleinigkeiten halt, das ist halt sowas, ja.

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 einem Problem, ehrlich gesagt.

Ja, das ist halt nicht lustig.

Und weil man hat halt auch irgendwelche Regeln von außen, die man gar nicht beeinflussen kann, an denen man sich halten muss.

Ja, man muss irgendwelche Türen aufmachen, da ein Kabel zwischenhängen, dann die Tür 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.

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 halt keine richtige Staging-Umgebung oder so.

Das heißt, was wir machen, ist, wir müssen quasi einmal Produktionsversionen komplett nachbauen und dann da ein Update drauf machen.

Weil wenn wir halt direkt eine neue Version bauen, dann kann es ja sein, dass das anders ist, als Produktionen zu updaten.

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

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

Und dann muss er am Ende, weil wir halt Budget und so, musst du halt die ganze Station-Gegend erstmal wieder abreißen, bevor Produktion dann anfängt zu bauen.

Deswegen dauert das halt auch alles immer so lange.

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

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

Also ich glaube, wir hatten es ja vorhin ganz kurz schon angerissen, ich glaube, eine Sache, die, wenn man so ein Package baut, die wirklich so ein bisschen 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 vorletzte Jungle Con diesen schönen Vortrag, DocSoy 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 es, also selbst in der, in meiner eigenen Firma, wo ich ja echt jetzt keine weiten Wege zu den Leuten habe, ja, wenn ich sage, hey, da ist das drin, nutzt das mal, das ist halt eine Blackbox.

Also selbst wenn du dann irgendwie, dass sich dann doch mal jemand irgendwie den Code reintraut und da mal rumguckt, wenn er halt nicht ordentlich dokumentiert ist, ich meine, vielleicht mal irgendwo ein kurzer Doc-String oder so, ist es schon schwierig.

Also da wirklich mal das irgendwie zusammenzuschreiben, das habe ich jetzt tatsächlich auch im letzten Quartal relativ viel gemacht und hab dann mal bei Read the Docs da so ein bisschen Markdown mit Sphinx gepublished.

Also Sphinx komplettes Markdown.

Irgendwie ist ein bisschen nervig mit Restructure Test geht das immer besser.

Naja, ich komme mit dem Dokumentformat irgendwie nicht.

Also ich habe.

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

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

Man kann das hintereinander 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 ziemlich kaputt, der Adapter, ja, aber.

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 Haut, das wäre wahrscheinlich jeder ein Hautune, wie du vorhin bei deiner, also dass du sagst, hey, guck mal, ich habe diesen Use Case, ich möchte wie Datenbank 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 ist denn, warum willst du das denn überhaupt nutzen, warum hilfst, 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 Doc Swing dann auch so reinschreiben, was das dann halt macht.

Das macht meistens relativ viel Sinn oder merkt halt, dass nochmal der Name, den man da verwendet hat, irgendwie Quatsch ist und das macht man dann noch ein bisschen hübscher und dann so kommt man auf eine relativ gute Qualität, glaube ich.

Das ist aber dann wirklich essentiell, dass man mit anderen Leuten das gemeinsam macht.

Das ist auf jeden Fall eine gute Idee.

Wobei dann ist auch die Dokumentation in Ordnung.

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

Die ist halt irgendwie hüperschnell 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 läuft, und dann muss ich dann ein oder zwei Wochen da nochmal Zeit reinstecken, wenn ich mir jeden Tag irgendwie dann zehn Minuten wieder der Doku anpasse, die ist halt dann nach diesen zwei Wochen einfach nicht mehr benutzbar.

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, da hatte ja der Kalten Gibson jetzt bei dieser DjangoCon einen Vortrag bezüglich wie dieses Static Dynamic Websites, Static Dynamic Pages hieß ich, glaube ich.

Mit Swings und.

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

Müssten wir

nochmal nachschauen.

Du benutzt das dann einfach Doc Strings irgendwie.

Nee, 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.

Machst du das nicht auf die Django-Docs, die da der Dokumentation, die tatsächlich in diesem Format irgendwie selber ist?

Möglich, ja, ich glaube.

Auf jeden Fall, da hattest du 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 Doc-Strings, weil die musst du halt, die sind eh im Code, aber wenn du halt diese, diese, zum Beispiel so eine Auto-Dokumentation, bei mir läuft es jetzt halt irgendwie, ja, es ist halt schon irgendwie im Code drin, aber es ist auch jetzt irgendwie separat gehostet.

Und wenn du jetzt, bei Packages ist es eh schwierig, weil die laufen dann irgendwo, wenn du zum Beispiel sagst, ich möchte jetzt irgendwie Dokumentation für meine eigene Seite, also zum Beispiel, ich möchte irgendwie die Business-Logik und die Technik und irgendwie sehr detailliert das aufschreiben, muss ich vielleicht auch, wenn es irgendwelche Compliance-Sachen gibt.

Die hingegen 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 Linking reinbauen kannst und sagst, ja, Moment mal, du hast da was angefasst, du hast noch nicht die, du hast, ne, du hast dann das Marktdown nicht dazu angepasst.

Das sind, glaube ich, sehr, sehr coole Use Cases dafür, wenn man da halt wirklich, wenn das wirklich wichtig ist.

Also du hast halt dann die Nähe von Dokumentation, die eigentlich sich weit weg anfühlt, dass es irgendwo ein Marktdown-Datei, die irgendwo rumliegt 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 bringen, damit auch die Motivation erhöht, dass man es auch wirklich tut.

Also ich war ja echt Fan auch von diesen, also autogenerierten Sphinx-Docs, ja Autodoc aus den Doc-Sphings heraus und so, dass du einen halt so ein bisschen dazu zwingst, deine DocSings aktuell zu halten.

Aber noch besser sieht er tatsächlich, jetzt muss ich noch kurz verjochen, lassen wir bringen, dieses NBDev aus, weil man in Notebooks halt das Markdown auch direkt mit reintreiben kann, wenn das ordentlich aussieht.

Man ein Notebook hat, was ordentlich aussieht, ja, und was dann automatisch dann zur Dokumentation von diesem Code führt, das dann irgendwie aus einem Guss hat, das ist schon irgendwie sehr charmant für bestimmte Sachen.

Gerade wenn man, glaube ich, so Pakete neu entwickelt, irgendwie das dann hinterher nochmal angucken will, das ist schon schön.

Ja, ich sag mal aber 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 ganz gut.

Genau, das hast du ja sonst eigentlich, weiß ich nicht, wenn du jetzt irgendwie ein Django-Paket hast oder so, hast du das im Grunde kaum.

Insofern ist es da nicht so schlimm, wenn man das halt nicht in einem 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 das Paket bauen, also den Pull-Request dann das bauen, dann angucken, dann die Visualisierung dir anzeigen, erstmal bis dahin kommen.

Sondern ist es 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 ja so diverse Ansätze, also den kannte ich jetzt auch noch gar nicht, mir war das auch überhaupt nicht klar, dass die Django-Dokumentation das so macht, dass das halt irgendwie nur Jason 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 Servern ist sehr interessant.

NBDev finde ich interessant.

Ich finde voll interessant, was in dieser ViewJS.

ViewJS mache ich ja auch so ein bisschen, versuche ich auch reinzukommen, was die da machen, die nehmen ja.

Mit VidePress oder sowas machen.

ViewPress bzw.

VidPress jetzt, genau, das ist auch total toll.

Das sieht super aus.

Bitte?

Excuse me, Viet.

Viet, ja.

Ja, ich bin auch, das ist auch so blöd, wenn man dann irgendwie, habe ich auf einem View, äh, View-Meetup den Vortrag über VidPress gehalten und dann WhitePress gesagt oder sowas.

Und dann kam die erste Frage und jemand sagte dann Viet.

Und ich so,

ich habe es gerade eine halbe Stunde lang jedes Mal falsch gesagt.

Und ja.

Aber genau, so ist das halt.

Und das ist aber auch voll toll, weil was daran super ist, ist, dass man direkt sieht, wenn man was an der Dokumentation ändert oder so, das ist halt sofort alles live.

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 einer Webseite ist, es dauert nochmal, also während bei BeatPress oder so, das ist halt sofort da.

Man editiert es quasi live.

Das ist halt auch.

Aber so das rundum sorglose Ding für alles gibt es irgendwie nicht.

Es gibt so diverse, sehr interessante Geschichten, die so in Teilcommunities, äh, Communities irgendwie so entwickelt worden sind, aber.

Also ich würde auch fast sagen, also VidPress irgendwie, also ist schon nett für Markdown-Sachen.

Also Markdown-Sachen husten oder hochladen, aber das generiert halt immer noch nicht dein Content, ne?

Der muss man halt immer noch machen.

Nee, den muss man auch selber schreiben, aber man kriegt den damit sehr gut aus den Tinnen.

Also die ganze, also ich meine, die View-Dokumentation ist ja View Press, weil das kann halt noch 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.

Also, finde ich.

So gerade auch im Vergleich zu Django-Dokumentation.

Django-Dokumentation ist jetzt deutlich mehr und deutlich umfangreicher und vollständiger.

Aber die View-Dokumentation sieht schon besser aus.

Und also das sind ja noch so kleine Animationen und diese ganzen Geschichten, die halt bei View so drin sind.

Ja, ja, relativ einfach, dass da alles mit direkt auch als Paket kommt, das da rüber und dann funktioniert das einfach.

Das ist sowieso ein bisschen das Problem von Dango-Sachen immer, dass das immer so sehr statische Seiten sind immer.

Ja, aber nicht unbedingt, nein.

Warte, ja, wenn man das halt Headless macht, dann halt zum Beispiel wieder nicht, ne?

Aber das ist halt dann ohne welcher Overhead, das dann halt in die Projekte dann alles immer 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 liebern möchte.

Tja.

Das ist allerdings wahr.

Ja.

Ja, Pakete.

Hast du noch was, Ronny?

Du hast das noch.

Also tatsächlich, ich habe es 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 Typehinting zu nutzen.

Mit der Konto wäre es diskutiert, ob das gut oder

schlecht ist.

Also ganz radikal jedes Argument in jeder einzelnen Methode.

Ja, also gehintet.

Es ist immer ein bisschen schwierig, wenn du halt Klassen hast, die aus dem eigenen Scope kommen, weil du dann super schnell in den Circular Imports rennst.

Da ist es dann so, dass ich zum Beispiel sage, okay, wenn ich jetzt ein, keine Ahnung, ein User-Query-Set habe, weil das 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 das ist falsch.

Also wenn du halt eine.

Ja, es ist

halt der ist halt der Vater, ne?

Also es ist ja ein Haupttyp-Curry-Set.

Ja, ja, das ist ja nur die Base-A.

Nein, nein, 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.

Im Endeffekt, wenn ich halt nichts zurückgebe, also nicht Type hinter, dann weiß jemand nichts.

Wenn ich weiß, da kommt ein Queryset zurück, dann weiß ich immerhin schon mal, ehe das keine Liste.

Ja, aber okay, aber das ist schon besser.

Also war, also man macht das ja in sowas wie Type-Script oder sowas, so relativ detailliert, dass man irgendwelche Interfaces dann dafür baut, wo die dann halt dann die Typen extenden, die man einfach auch verwenden muss, weil ansonsten ist das ja falsch.

Also wenn du jetzt ein User-Query-Set hast, vielleicht hast du an einem Custom-Query-Set, wo du irgendwas Besonderes dran gemacht hast, irgendeine Methode, die andere Querysets nicht können oder so.

Und wenn du dann halt sagst, das ist nur ein Queryset und dann kommt da irgendeine Methode, die Querysets gar nicht können, das wäre irgendwie seltsam dann, ja.

Und das müsste eigentlich auch gelintet werden, finde ich.

Also du hast recht, es ist nicht ganz trendscharf.

Dadurch, dass ich das Problem mit den Circular Inpuls 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 mehr.

Verantwortung.

Also meistens finde ich es eh, also sehr sinnvoll ist es vor allem eh bei trivialen Datentypen, weil du halt dann, ob das jetzt irgendwie der Simulator und Float oder ein Integer oder sowas ist, das macht der schon, macht ja schnell irgendwie Berechnungen kaputt.

Aber ich finde das tatsächlich praktisch, wenn du, vor allem, wenn man so helper-Methoden oder irgendwie Sachen hat, also wo du dann, wo andere dann meinen Code nutzen, ist ja total praktisch, dass dir dann direkt die Idee schon anzeigt, so, sorry, da stimmt irgendwas.

Genau, das ist, finde ich, auch das Wichtigste an diesen Typ ins Python, dass du halt tatsächlich, wenn du den Lint richtig konfiguriert hast, während dem Schreiben siehst, wenn du da irgendetwas brauchst und das ist wirklich praktisch.

Aber ich muss auch tatsächlich meistens nur für komplexe Dinge, also wo es fraglich ist oder wo du nicht genau weißt, was ist, dann sage ich halt direkt, dass das 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 dazu ü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 dann irgendwie von einer Klasse, da ist dann, der erste Typ ist immer, nicht Typ der erste, die erste Variable ist immer self.

Dann machst du Komma, Sternchen, Komma und danach deine anderen.

Und dieses Sternchen sagst du dem quasi, es kommt hier quasi kein normales Argument.

Dahinter kommen die Keyword-Arguments.

Das heißt, es ist verboten, dass du sagst, ich gebe den ersten Parameter normal rein.

Habt ihr verstanden, was ich meine?

Ja, also ein schlechter Klein.

Ein normales Argument geben, sondern nur Keyword-Argument.

Genau.

Und das finde ich jetzt, also bei manchen Sachen ist es natürlich Unsinn, ja.

Ich meine, wenn du eine Sache hast und das auch klar ist, aber insbesondere bei so Methoden oder wenn man mal irgendwie dann doch mal so vor so einer Funktion steht, wo dann irgendwie doch mal so drei, vier, fünf Sachen reingehen, was ja irgendwie noch so ein bisschen unlesbar ist.

Ja, da den User zu erzwingen, vor allem, wenn da mal einer hinkommt und das irgendwie ein bisschen refactorn möchte, dann ist er auf jeden Fall sichergestellt, dass niemand aus Versehen, also zum Beispiel, wenn man in die Reihenfolge tauscht, man möchte irgendwas da vorne rein, dann kann man das einfach machen, weil es sind der Keyword-Argumente.

Aber das schluckt der nicht, dass mit dem Ständchen den Rest einfach weg dann?

Ich würde dich gerade, wo der dann rausfällt.

Ne, man kann auch noch, dass ich sagen.

Also der Argumente bitte 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, darfst du nicht.

Also das ist sehr praktisch, weil ansonsten, das wäre ja blöd, wenn das passiert, was du sagst.

Nee, tatsächlich sagt ihr 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, ja, 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 auch immer 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 Allowed geht.

Gibt es da nicht doch irgendein Parameter für?

Ich habe da irgendwas.

Es gibt da irgendwas mit dem Slash, ich weiß es nicht mehr genau, es gibt, äh, aber ich weiß es jetzt auch nicht mehr genau, es gibt also Position-Ony Arguments, es gibt auch Keyword-Ony Arguments mit dem Stern.

Ja, aber genau, also ich, ja, ich würde ja jetzt sagen, genau, wenn es, wenn man viele Argumente hat, dann ist es 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, die Idee, das ist vervollständigt, okay, dann geht es vielleicht, aber ansonsten.

Vor allem, wenn man ja immer durchpippen muss durch irgendwie mehrere Ebenen.

Was ich dann oft sehe, ist halt irgendwie, oder wo ich denke, da macht es dann nicht mehr so viel Sinn, ist halt, du hast eine Riesenliste, also wo dann Leute dann anfangen, okay, Funktionen geht auf, Klammer auf und dann kommt dann halt irgendwie so eine riesen Liste von Zeug, ja, dann Klammer zu und dann kommen erstmal 100 Zeilen Überprüfungen, was man denn da bekommen hat und viele Behandlungen, 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, es ist schon interessant.

Ja, überhaupt diese ganze Type-Pending-Geschichte oder so, da bin ich auch noch nicht so richtig wahr.

Also ich mag es natürlich, wenn die Idee mir hilft und irgendwie Dinge vorschlägt oder kringelt, wo ich dann einen Fehler gemacht habe.

Kann Wim da auch selber, bitte?

Kann Wim das auch gutes Linting?

Ich weiß es gar nicht, habe das nie wirklich verwendet, glaube ich.

Also irgendwie

aus dem Aufschreibt bestimmt ja.

Es 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 meine Sendung zu machen und muss sich mich damit beschäftigen, das wollte ich auch schnell mal tun.

Das ist voll 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 Pipeline 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 Backtracker, 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 Pipeline-Version oder der Bild läuft durch oder meine Docs funktionieren.

Gibt es 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 einfach aufwenden an die Seite.

Du hast ein bisschen Convenience dazu nutzen.

Genau, Convenience und auch die Leute einfach so ein bisschen so, hey, guck mal, ich weiß, was ich hier tue, ne, ich habe ja irgendwie an alles gedacht.

Auch bei diesen, bei der gibt es auch so Metadaten, wo du zum Beispiel sagen kannst, in welchem Status befindet sich das.

Ist das gerade eine Alpha?

Ist das eine Beta?

Ist das Production Ready?

So, da kannst du genau auflisten, welche Dependencies, was ich vorhin schon meinte, bei der Matrix, die und die Python-Version unterstütze ich, die und die Django-Version unterstütze ich.

Ist halt super praktisch, wenn halt jemand kommt, der gerade ein bisschen browserst bei PyPy und einfach sucht, okay, ich möchte das 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 unterstützt das, steht da.

Da muss man nicht irgendwie sich lange durch Dokus durchgraben oder weiß der Geil, 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, das das sehr ausführlich nutzt, dann gucke ich mir GitHub an und klau dann da die Sachen.

Und schaust mir ab, was man da alles machen kann.

Also ein gut geklautes Hype gewonnen.

Ja, ja, auf jeden Fall.

Oh, das wollte ich eben noch sagen, das habe ich dann irgendwie wieder 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, mache ich sowieso ein Checkout von dem Repository, dass ich dann in das Paket selber reingucke.

Nee, eigentlich auch nicht.

Ja, insofern, genau.

Ich mache das inzwischen auch so, dass die Tests halt nicht mehr in dem Paket mit drin sind.

Ja.

Ja, man kann schöne Sachen mit Paket machen.

Auf jeden Fall.

Habt ihr noch was?

Ja, also ein großer Teil, den wir jetzt nicht haben, aber vielleicht machen wir den dann auch mal irgendwann anders, weil es jetzt auch gar nicht so.

Das betrifft ja auch eher wieder so den Data Science-Teil Konda.

Das ist natürlich auch wieder eigene Pakete.

Ah ja.

Im Grunde auch eigener Teil wäre halt sowas wie irgendwie baue ich ein Binary, einfach ein Executable-Ding irgendwie bauen kann.

Das können wir jetzt, könnte man hätte man jetzt auch hier noch machen können, aber ich bin nicht vorbereitet.

Keine Ahnung.

Muss man sich das Ganze nochmal angucken, wie das so funktioniert.

Ich habe Gottes 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.

Achso, wieso?

Also es ist relativ intrusiv.

Das heißt, man kann es nicht einfach so daneben in den Rest backen.

Also ich muss zum Beispiel, um es mit Pi-Enf zu benutzen, als Pi-Enfunktionieren, immer so ein bisschen rumhacken, dass das vernünftig geht.

Ja, ja, manchmal funktioniert es halt auch nicht mehr richtig, das stimmt schon.

Oder es macht halt irgendwelche Pfade kaputt oder schreibt sich in irgendwelche Systemkonflex rein, wo es eigentlich gar nicht 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, was nicht.

Fällt mir jetzt auch nichts mehr ein?

Ja.

Ja, ich glaube, eine Sache, die ist noch ganz cool, also ich habe tatsächlich gemerkt, dass selbst wenn ich, also wenn ich Code schreibe, dann bemühe ich mich den ja auch, dass der ordentlich ist, dass der getestet ist und so weiter.

Aber sobald man dann anfängt, den in ein Package zu legen, fallen einem sofort noch zehn Use Cases ein, die man eigentlich noch mit abdecken sollte.

Und die Code-Qualität ist auf jeden Fall nachher immer nochmal 20 bis 30 Prozent besser gefühlt, wenn ich das wirklich package-ready gemacht habe.

Einfach weil man dann denkt, ach komm, irgendwie du hast so ein Spezial von deinem Projekt, ja, das weiß ich nicht jeder, weiß ich nicht, du hast so ein separates User-Model, ja, ist okay, das lasse ich einfach so nachdenken.

Nee, das funktioniert nicht so, ne?

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, wenn man irgendwas Cooles gebaut hat.

Ja, auf jeden Fall.

Ja, wollen wir noch Picks machen?

Ich wollte gerade habt ihr Picks, der macht.

Etwas, ja.

Ja, okay.

Dann bitte dann.

Okay, dann fange ich direkt an.

Allerdings nicht, äh, es ist kein Paket oder keine Software, sondern es ist ein Artikel, ist aber auch lang.

Viel Spaß mit.

Auf ein Hinterschlager ist Subclassing in Python, Redux.

Ich weiß nicht, ob wir den.

Das ist jetzt irgendwie.

Den kannst du das nochmal wiederholen, bitte?

Subclassing in Python Redux.

Am 20.

Juni rausgekommen, ist jetzt, also gefühlt noch gar nicht so lange her, vielleicht eine Woche oder müsste eigentlich etwas mehr als eine Woche vielleicht sogar.

Ja, ich glaube eine Woche, zwei Tage Jochen.

Kann sein.

Ist auf jeden Fall sehr interessant, genau, schöner, langer Artikel, wo er irgendwie so seine Erfahrungen über die letzten paar Jahre beschreibt und was alles nicht funktioniert, der 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, beschreibt da, also das ist auf jeden Fall, sollte man sich mal die Zeit nehmen, wenn man so einen langen, dunklenachmittag, ach, jetzt ist gerade Sommer, Zeit hat dich das mal durchlesen und das ist viel lehrreiches Zeug drin.

Sehr, sehr gut.

Guter Artikel.

Okay, interessant, interessant.

Ronny, hast du auch ein Picket der Woche?

Ein Modul, das erwaschen möchtest.

Ich glaube tatsächlich gerade nicht aus dem FF.

Oder irgendein Talk oder irgendwas Interessantes.

Ja, gut, ich meine, der Dominik hat es ja gerade schon irgendwie fünfmal angesprochen, dieser erste Talk von der DjungoCon mit dem Programming for Pleasure.

Ach ja, okay.

Ich meine, das war so schön herätisch.

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, ne, als Firma?

Wie war das eigentlich sozusagen aus dem Blickwinkel?

Ja, es ist schon, also wir haben uns alle immer, also wir haben mit ein paar wenigen Leuten im Büro geguckt.

Also ja, ein paar Leute, die 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 dann alle immer schon gefreut, wenn dann unser nagelneues Promo-Video dann da über den Bildschirm gelaufen ist.

Und ja, ist auf jeden Fall auch cool, also irgendwie da das mit zu unterstützen und auch irgendwie ein bisschen, irgendwie so ein bisschen was zurückgeben zu können.

Weil ich meine, wir nutzen ja schon Django irgendwie sehr, sehr viel und ja, ansonsten da halt so ein paar Möglichkeiten.

Du kannst dann irgendwie einen Job-Job auf vor einem Slack posten, du kriegst einen Kanal, den du dann bearbeiten kannst.

Das haben wir tatsächlich gar nicht so wirklich gemacht, weil, ja, ja, wir hatten da irgendwie gar nicht so drüber nachgedacht, sage ich mal.

Also, weil es weiter so, ja klar, wir sind im Slack und da schreibst du mit den Leuten und da haben sich noch ein paar Leute noch gefragt wegen den Bewerbungen, wie es denn damit aussieht und wie es denn ist mit, wenn man halt irgendwie kein Deutsch kann und mit Remote und alles Mögliche.

Aber da haben halt manche Firmen 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 doch so ein bisschen ein anderes Element dazu gibt, weil das ja, es ist ja irgendwie, also ich weiß gar nicht, wer das war, ob das Laudswarm war.

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.

Und die Sixfeet alle.

Genau.

Und das ist echt schon ganz cool, weil das ist irgendwie auch eine ganz coole Art, mit den Leuten so auch jetzt als Firma zu interagieren, ohne dass man jetzt irgendwie direkt mit der Mega-Werbekollen oder sowas kommt und so, hey hier, ich will euch was verkaufen.

Von daher denke ich mal, also wir haben ja jetzt schon, das weiß ich, die dritte Conne-Folge, die wir gesponsert haben.

Achso, okay, das haben wir auch gar nicht geklappt.

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, es 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 deinem Laptop, aber das ist schon, ich denke mal auch, dass ich tippe mal, dass dieses Hybrid-Ding wird auch einfach bleiben.

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 Drang-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.

Das ist halt 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.

So ein low-levelig im Busch.

Ich bin noch nicht so ganz sicher.

Ich finde das schon wichtig, diese Inklusion, aber so live treffen wir.

Ich vermisse zum Beispiel, dass 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 ja doch Leute, die da halt einfach vollkommen zufrieden sind, das so auch als irgendwie als so ein Radio-Event oder sowas, ja, oder so ein Fernsehen halt irgendwie nebenherlaufen zu lassen.

Es ist auch manchmal ist das weniger Commitment, es ist mehr so Leeching.

Und die Frage ist halt, also 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, dass das irgendwie, ich habe noch nicht herausgefunden, 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 echt immer ausverkauft, also die vor-Ort-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 Dango Meter, jetzt werden wir auch, ich meine, es war jetzt noch, 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.

Beim nächsten Mal müssen wir 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, ne, socializen.

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, kann man jemanden in der Eifel oder sowas, also jetzt hier, ne, Körnerraum, Eifel ist ja irgendwie so.

Genau.

Jan zwei draußen.

Ist dann halt teilweise Abend ziemlich schwierig, dann hin und zurückzukommen, wenn du dann irgendwie nicht extra mal Auto fährst oder so.

Und einfach die Leute noch mitzunehmen, wenn die da Spaß dran haben, das fände ich schon gut, das möglich zu machen.

Wie gesagt, wir müssen mal gucken, welchen Modus wir nachher dann tatsächlich fahren, aber das ist da, ja, ich tippe mal, dass wir wahrscheinlich auf Hybrid gehen.

Du warst auch in Berlin beim Dungometer Pacetität.

Ja, genau.

Ich bin vom Philipp, der ist jetzt seit Januar der Organisator davon angeschrieben worden über LinkedIn, habe mich gefunden und hatte mich noch 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 the DongoCon.

Okay.

Ja.

Zum Besten gegeben.

Zum Besten gegeben.

Ich habe jetzt über Packages geredet, da 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 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, dass mir zu sagen, irgendwer ist doof oder so, sondern das waren wirklich so meine Eindrücke, die ich quasi beim Davorsitzen acht Stunden am Tag mir aufgenommen habe und einfach dann so, ja, keine Ahnung.

Also zum Beispiel gab es einen Talk über diese Interactive Shells.

Das ist einfach nicht meine Welt gewesen.

Ich habe noch nie andersweise mit diesen Sachen arbeiten müssen und mehr als irgendwie mal mit der Django Shell mal kurz ein Model irgendwie aus der Datenbank holen, habe ich halt noch nicht gemacht, so ungefähr.

Und dann 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 Qualitä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 Breitenwissen ist, aber das ist eben auch im Endeffekt das, was ich dann da so ein bisschen erzählt habe.

Einfach.

So, hey, wenn ihr euch dafür interessiert, ist das cool und so, dass man halt dann, weil wenn man nicht dabei war, dann trotzdem vielleicht so ein paar Ideen hat, wenn es dann irgendwann mal auf YouTube kommt.

Ich glaube, die wollten, dass die so nächste Woche mal online stellen, die Talks.

Weiß gar nicht, wann die auf das schon kommt.

Das müsste ja genau dieses Wochenende sein.

Wann war die Tango kommt?

2.

Juni oder so?

2.

bis 6.

Juni, ja.

Genau.

Und jetzt haben wir ja auch ein bisschen.

Ja, morgen

bis 2.

Also genau, mal gucken.

Ich werde das auf jeden Fall dann auch noch in die Shownotes packen, wenn sich das

geben soll.

Sehr interessant.

Achso, ich habe auch noch einen Pick der Woche.

Ja.

Und zwar, ich weiß nicht, ob ihr TLDR kennt.

Das gibt es doch auf PiPy und das ist eigentlich so ein Shell-Tool.

Ihr kennt bestimmt Man, ne?

Linux-Command, um sich die Main-Pages anzugucken von einem Command, was macht denn das?

Und TLDR geht ein 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, gibt es gibt 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, 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 erstmal 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 nochmal mit dem Grab oder mit dem Find.

Und dann weißt du direkt, ah, so benutzt man das.

Ah, total super.

Und cool.

Gehe ich on Short auf einer kleinen Seite.

Das ist auch meistens wirklich nur, pass alles auf eine Seite, kannst du angucken.

Mega geil, kann ich echt empfehlen.

Das habe ich gefunden als Teil über die modernen Linux-Commands oder sowas.

Kennt ihr das?

Muss man vielleicht auch unbedingt nicht shownos?

Das heißt tatsächlich Modern Linux.

Muss ich kurz gucken.

Ja, genau, Modern Unix, Entschuldigung, nicht Linux, es gibt ja einen Unterschied.

Von Ibrahim Deef.

Und das ist sehr schön.

Gibt es die verschiedensten Erweiterungen?

Okay, doch, das habe ich, genau, Watt, Exai, ja, ja.

Genau, genau, genau.

Da ist auch TLDR dabei.

Und viele, also tolle Implementierung auch in Rust und so, aber das ist sehr nice, wenn man modern Linux UNIX mag.

Ja, der TLDR ist auch auf PiPi tatsächlich und kann uns hier einfach die Shell ziehen und macht Spaß.

Cool.

Ja, sehr cool.

Ja, wunderbar.

Muss ich mir auch mal angucken.

Folgend.

Ja, ich glaube, wir sind am Ende für diese Durch.

Vielen Dank, dass du wieder da warst, Ronny.

Vielen Dank.

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.

Passt trotzdem ein bisschen auf und bleibt gesund.

Und ja, bis zum nächsten Mal.

Alles klar.

Tschüss.

Tschüss.

Ciao.