Transcript: Python Packaging

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

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

Entschuldigung, dass ich wieder eingeschaltet habe.

Was machen wir heute? Wir wollten ein bisschen was über Pakete besprechen.

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

Hi, Jochen.

Hallo.

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

Hi.

Hallo.

Ich bin der Dominik.

Ja.

Ja.

Ja.

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

Habt ihr News?

Nee, ich bin zu irgendwie nicht viel gekommen

und habe auch keine Newsletter oder sonst irgendwas gelesen.

Daher nicht viel.

Also es kam tatsächlich der Copilot auf GitHub heute raus zum Coden.

Das fand ich ja ganz interessant.

Das ist jetzt keine Python-News, aber man kann sich da anmelden,

irgendwie eintragen in so einer Testerliste.

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

Was macht das denn?

Das ist ein Copilot für GitHub, der, wenn man Docstring schreibt,

automatisch die Funktion baut, der für verschiedene

Sprachen funktioniert. Sieht ziemlich

nice aus. Also so die Demo, aber wenn

das mal richtig gut funktioniert, irgendwie mit

Machine Learning dahinter wahrscheinlich so ein bisschen,

vielleicht einfach einen coolen Dockstring und der baut

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

Ja, ich habe das irgendwie, ich habe nur so ein

Animated GIF

auf Twitter oder so gesehen, wo da

jemand bezeichnet Learn was gemacht hat und das sah

schon gut aus, aber

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

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

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

Ja, ich glaube, lesen muss man es natürlich schon, aber es ist ja relativ

super, um wahrscheinlich bekannte Patterns so zu verstehen

und auch für Sprachen, die man vielleicht noch

nicht so gut kann, dass man halt so grundsätzliche Konzepte

da sehr schnell mitlernen kann.

Das muss auch super interessant sein, außerdem wird man gezwungen,

Dokumentationen zu schreiben, direkt

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

Also es ist halt die Frage, wohin das hinschaut,

wenn das halt nur KI-gesteuert ist, irgendwann

je nachdem, wie gut die Qualität der Leute ist,

hier und da zu schreiben, was dann dabei rauskommt, weiß ich nicht.

Ja, das ist die durchschnittliche

GitHub-Code-Qualität, ich meine, wenn das

jetzt, also kann ja eine Verbesserung

sein. Ja, genau. Also ich finde es

wirklich interessant und es sah auch echt top aus.

Documentation-Driven-Development

oder... Irgendwie so.

Specification-Driven-Development.

Ja, also diese Beispiele

auf der Seite vom Co-Piloten da, die sahen echt

schick aus, auch in Python, die es da gab.

Okay, ja, cool. Das ist auf jeden Fall

eine Neuigkeit, ja.

Ja, haben wir noch was?

Ich glaube, was hast du gesagt?

Python 306, ja, egal.

Ja, ist vor drei Tagen oder so rausgekommen.

aber ich weiß ehrlich gesagt

nicht mal, was der Unterschied ist.

Voll gut, nur so eine Erinnerung,

dass man das jetzt mal dann installieren könnte.

Aber ansonsten.

Nichts Großes passiert. Dann würden wir doch direkt

zur Folge kommen, oder fällt dir noch was ein, Ronny?

Ist doch eigentlich eine gute Überleitung, so GitHub

Packages. Stimmt.

Was ist denn das, ein Package?

Genau, das ist das Thema, ne?

Packaging.

Was ist das? Wie macht man das denn?

Wie spricht man das aus? Ganz wichtig.

Ein Paket. Also ihr wollt irgendwas machen wie ein Paket schreiben, ein Modul schreiben. Was ist ein Modul? Und das Veröffentlichen, vielleicht ist Veröffentlichen eine der Sachen, die man damit machen will mit einem Paket? Oder Wiederbenutzen vielleicht?

Ja, selbst wenn man das nur irgendwie, wenn man einen Code miteinander teilen will, ist es wahrscheinlich schon eine ganz gute Idee, unter Umständen das halt als Paket zu tun und nicht direkt als Repository.

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

Ja, also es gibt unterschiedliche

Arten von Paketen.

Das ist vielleicht schon mal so ein grundsätzliches Ding, mit dem man

anfangen kann. Also es gibt halt zum Beispiel

oder ich weiß nicht, wo wir damit

anfangen, oder mit der Geschichte von

Packaging. Ja, okay, ich bin gespannt.

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

Ja,

da gibt es auch Pakete, ja.

Vielleicht nur so ganz kurz,

es ist halt leider verwirrend, es ist kompliziert

und es ist komisch und es ist alles nicht so einfach in Python

leider. Das hat glaube ich

angefangen alles irgendwie 1998 mit

Distutils

und das ist auch

in der Standardbibliothek, ist da immer noch drin.

Also es geht eigentlich darum, wie gebt ihr denn euer Programm

irgendwem, der es dann ausführen

möchte? Ja, wie

kann man Code irgendwie,

ja, wie kann man Code so verpacken, dass man das

irgendwo anders dann halt einfach nur das Paket

installiert und nicht den kompletten, das komplette Repository.

Ja, oder vielleicht, wenn man noch nicht mal Python hat

oder so, oder der weiß dann gar nicht,

was für einen Computer der hat oder verschiedene

Herausforderungen. Genau,

Und dann irgendwann kamen halt Setup-Tools dazu.

Damit hat man dann zum ersten Mal...

Vielleicht ganz kurz noch, wenn wir jetzt schon mal wieder

bei Python-Podcast noch ein bisschen einsteigen.

Was ist denn DistroTilt?

Genau, das ist halt so ein Ding, um zum Beispiel,

ja, wenn man jetzt in einem Verzeichnis ist,

wo man den Code hat, daraus irgendwas zu bauen,

was man dann als Paket weitergeben kann.

Und da kommen auch an so ein paar von den Begriffen,

meine ich jedenfalls, her.

Sowas wie S-Dist zum Beispiel oder B-Dist.

Aber ich weiß nicht, ob es da schon wirklich dabei war.

Ach so, ja.

Es ist halt Source Distribution

und

sagt eigentlich im Grunde, dass man halt nur den

Code irgendwie ins Paket packt, also den

Source ins Paket packt und dann halt auf

dem Zielsystem halt eventuell noch, wenn

da Extensions, zum Beispiel C-Extensions oder so

drin sind, muss man die dann halt noch

bauen. Also es ist halt noch nicht gebaut.

Es sind nicht die PYC-Files, sondern es sind nur

tatsächlich die

.py-Files.

Und weil die

PYC-Files, das hängt auch von

der Interpreter-Version ab und so,

Und dann gibt es halt die BDIS, also die Build Distribution Pakete, genau, und das sind halt irgendwie TAR-Balls vor allen Dingen gewesen oder manchmal auf Windows, glaube ich, auch ZIP-Files, weiß nicht genau, aber es ist noch kein richtiges Paketformat.

Und dann kamen irgendwann Setup-Tools dazu und weiß nicht, irgendwann Anfang der Nullerjahre, keine Ahnung wann genau, und da war das Ziel halt dann so ein Paketformat zu haben, das hatte man dann mit X auch, aber das war es, was auch mehr oder weniger ein ZIP-File war.

und inzwischen sind es Wheels,

das ist auch mehr oder weniger der Fall.

Aber

so ein bisschen

sind die Dinge schon anders, also Wheels sind jetzt

deutlich schneller, kann man deutlich schneller auspacken

und verwenden als X.

X werden eigentlich nicht mehr verwendet.

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

worden ist und dann sind Dinge

auch wieder zurück nach Setup Tools gegangen

und Setup Tools ist aber nie Teil der

Standardbibliothek geworden.

Distutils

war es dann aber schon immer schon lange.

So dass heute ist es halt so, es gibt halt Dinge, die macht Distu-Shills, wenn man ein Paket baut. Es gibt Dinge, da benutzt man Setup-Tools für, was ein bisschen komisch ist, weil das ist halt nicht in der Schaltebibliothek, man muss dafür Setup-Tools installieren. Und Setup-Tools hat dann wiederum Plugins für bestimmte Sachen, wie zum Beispiel, wenn man Wheels bauen will, dann gibt es halt das Wheels-Paket, das man dann noch installieren kann und das bringt dann halt ein Plugin für Setup-Tools mit, womit man dann halt auch Wheels bauen kann.

Ja, okay.

Das klingt aber so, als geht das halt nicht

out of the box. Und da brauchen wir schon noch andere Sachen.

Ohne C-Compiler geht das wahrscheinlich dann nicht?

Doch, also wenn man

zum Beispiel einfach nur

reine Python, also wenn der

Code, den man geschrieben hat, einfach nur

Python-Code ist, dann

braucht man eigentlich sonst nichts zu machen.

Dann ist auch eine Source-Distribution

im Grunde schon ausreichend.

Aber wenn man

jetzt halt C-Extensions dabei hat oder sonst irgendwas,

was komplett werden muss, dann braucht man halt irgendwie

so einem Compiler und

muss halt

ja, dass dann halt auch da

Setup-Tools kein Konzept von

Cross-Compiling hat, muss man halt auch

für alle Architekturen, für die man Wheels bauen will

zum Beispiel, auch tatsächlich eine

Maschine da haben, die die Plattform

halt, also eine Maschine der entsprechenden

Plattform da haben.

Was halt auch unter Umständen so ein bisschen doof war.

Das war jetzt zu der Zeit, wo auf Apple Silicon

umgestellt wurde, haben ganz viele Leute plötzlich

gesucht nach, irgendwie habe ich irgendwo einen SSA-Zugang

auf eine Maschine mit M1 oder so.

damit ich das mal da bauen kann, weil

ansonsten kann man halt keine Wheels bauen. Das geht halt nicht. Das kannst du nicht

auf einer Intel-Maschine

machen.

Und das ist alles so ein bisschen

hässlich. Und, ah ja, Gott.

Ja.

Es ist kompliziert, leider.

Okay, dann habe ich Wheels gebaut und

die kann ich dann irgendwie auf PyPI stellen

und habe ein Paket.

Aber nicht nur die Wheels, sondern auch Source-Distribution

und Build-Distribution kann man auch

auf PyPI stellen.

Und passiert auch oft.

Und oft muss man es dann auch selber kompilieren noch,

wenn es halt keine Wheels gibt zum Beispiel.

Ich habe jetzt auch hier so ein

M1-Mac und das passiert regelmäßig, dass

ich irgendwie Pandas oder NumPy und dann

ein Großteil des Zeugs unten drunter muss halt dann

noch kompiliert werden und das dauert halt

relativ lang. Zum Beispiel, wenn jetzt man sowas

installiert wie Python 3.9.6 irgendwie,

wenn es gerade mal rausgekommen ist, dann gibt es halt für Pandas

und NumPy noch keine Wheels und dann

wird dann halt schön selber kompiliert,

was dann halt mal ein paar Minuten dauern kann.

Auf dem M1.

Ja, und einen zur Verzweiflung treibt,

wenn irgendwelche Details in dieser Compile-Pipeline

und irgendwann der Vortragskompiler nicht richtig ist

oder keine Ahnung, irgendwas bei der Emulation

des Intel-Prozessors nicht richtig funktioniert oder so.

Und dann kriegt man sehr, sehr komische Fehlermeldungen

aus den Tiefen von irgendwelchen Compiler-Toolchains.

Ja, okay.

Ja, also tatsächlich auf anderen Systemen bauen zu wollen,

an neuen Versionen, ist dann vielleicht immer nicht ganz so einfach.

Nee.

Aber das Gute ist, dass man tatsächlich auch,

wenn man jetzt, vor allem wenn man jetzt eigentlich mal anfängt,

dass man ja dann doch eher in der reinen Python-Welt

bleibt und dass man dann das auch relativ

entspannt einfach

ohne irgendwelche großen Probleme

die Packages erstens bauen kann und zweitens dann

auch die dann auch wieder leicht installieren kann.

Also man kann sich relativ viel von diesem Komplexitäts-

Overhead sparen, indem man quasi

keine externen Libraries verwendet

oder sowas, ja. Genau, ja.

Also reines Python, das

ist eigentlich relativ einfach dann, ja.

Also das Einzige, was halt dann

mit in den

Build Distributions drin, das sind halt die

PYC-Files und

PYC, also ansonsten

muss die halt noch einmal von PY nach

PYC verwandelt werden, aber das ist auch alles

das merkt man heutzutage gar nicht mehr.

Und dann hat man so ein Paket

und dann hat man das auf PyPI und dann kann

jeder das laden

über PIP oder

sowas.

Ja, und die ganze Dokumentation

dazu, ich habe

mich ehrlich gesagt nicht wirklich

vorbereitet, aber ich habe einmal

geguckt,

was gibt es

denn, habe ich irgendwelche Bücher

zufällig, wo was drinsteht über Packaging

und da gab es irgendwie ein Buch

Python Expert Programming, da war ein bisschen was drin,

ein Kapitel und

ansonsten

ja, hier klingeln

Dinge, das ist immer so was,

Telefon auf Flugmodus stellen.

Das ist ja immer eine Checkliste

machen. Wird das ICQ-Bimmel im Hintergrund?

Du kennst das.

Oh ja, das ist lange her.

Was sind hier der Flugmodus?

Da ist er doch.

So.

Ja.

Genau. Also die

autoritative Quelle für Dokumentation

über dieses ganze Packaging-Thema

ist

packaging.python.org, also die

Python Packaging Authority,

PyPA nennt die sich auch.

Und da kann man das alles, also die ganzen Details,

die ganzen fiesen Details, die stehen da alle drin.

Und was mich sehr gefreut hat,

das ist genauso aufgebaut

wie, es gab da ja,

das hatten wir das letzte Mal auch schon von,

documentation.divio.com

Ja.

Sozusagen, also es gibt auch einen schönen

Vortrag

eben von Daniele

Pruschida

über... Der ist schon wieder.

Der ist schon wieder, genau. Wie schreibt man eigentlich Dokumentationen

sinnvollerweise? Und der teilt das halt auf.

Naja, es gibt halt unterschiedliche

Quadranten und unterschiedliche

Zielrichtungen. Und dann schreibt man halt

Tutorials, How-To-Guides, Explanations oder

Reference-Documentation.

Und das macht man alles mit Pleasure?

Er hat mit dem

Vortrag Programming for Pleasure gemacht. Genau, das war

dieses Jahr. Das war, glaube ich, hier

wo er über Dokumentationen Vortrag gemacht hat, war 2017

oder so. Kann man sich auch angucken.

Haben wir letztes Mal schon verlinkt.

in der JagoCon Europe-Episode sehr empfehlenswert.

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

Da sieht man halt, genau, sie machen Tutorials,

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

und dann gibt es dann halt irgendwie auch noch eine Referenzdokumentation.

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

Das fand ich irgendwie...

Muss ich auch mal machen für meine Dokumentation.

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

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

Genau, braucht man das alles gar nicht.

So ein Quatsch, Dokumentation.

Ich versuche tatsächlich,

alle Sachen, die ich wahrscheinlich wieder vergesse,

so aufzuschreiben,

dass da auch jemand anders, der das vielleicht liest,

dann auch noch machen könnte.

Meistens ist man schon selber in einem halben Jahr und freut sich drüber.

Ja, genau.

Das ist immer ganz nett.

Man ist auch schneller beim zweiten Mal,

wenn man halt einfach seine eigene Doku lesen kann

und sich nicht immer komplett von neuem irgendwo einarbeiten muss.

Ich finde tatsächlich, dass man auch mit inneren Dokumentationen

sehr viel gewinnen kann.

Ich habe mir mal irgendwo mal abgeguckt,

dass wenn man, sage ich mal, eine Methode hat,

die vielleicht 20, 30 Zeilen irgendwie relativ viel macht,

also du hast ein If und eine Schleife und keine Ahnung was,

dass man mit so Pünktchen arbeitet,

dass man sagt so, okay, hier mache ich jetzt das Punkt, Punkt, Punkt

und wenn das zutrifft, Punkt, Punkt, Punkt

und irgendwann kommst du halt zu dem Punkt, wo es halt vorbei ist

und dann passiert dieses und dann passiert jenes.

Das heißt, du kannst es halt mehr oder weniger wie so ein Buch lesen,

also genau den Pfad, der dich interessiert.

Habe ich mir irgendwann mal abgeguckt

und das mache ich eigentlich öfters mal,

ohne dass man jetzt da so einen fetten Dockstring drüber schreibt,

weil ich finde, der liest sich irgendwie.

Man ist ja irgendwie so ein bisschen faul.

Eigentlich gar nicht das Thema.

Ja, also wobei, ich weiß nicht,

bei Dokumentationen innerhalb von Sourcecode

oder Kommentare in Sourcecode finde ich immer ein bisschen schwierig.

Also es kommt darauf an, was es ist.

Manchmal auch natürlich stellen, wo das total sinnvoll ist.

Aber manchmal ist es halt auch echt,

weil das tendiert auch dazu, dann irgendwie so auseinanderzulaufen.

Also warum man so bestimmte Sachen macht,

die irgendwie komisch aussehen,

dass das vielleicht manchmal gar nicht so schlecht sieht.

Nee, das ist genau, genau, durchaus sinnvoll.

Aber, ja, von, na, wie heißt er noch, Dingsda, Clean Code, Uncle Bob, der sagt immer, das Erste, was er macht, wenn er durch Code geht, ist halt die ganzen Kommentare entfernen, weil sie verwirren nur, weil, ja, aber es kommt halt drauf an.

Also ich meine, es gibt halt so die Fälle, wo es klar ist, dass es verwirrend ist, aber es gibt halt auch die Fälle, wo es total sinnvoll ist.

Ich finde, das kann sehr viel Vertrauen schaffen.

Also wenn ich ein Package mir angucke, also jetzt in externer Sicht, und ich überlege, ob ich das nutzen möchte und vielleicht auch produktiv nutzen möchte und da ist halt gar nichts dokumentiert, dann habe ich direkt schon mal so ein großes Fragezeichen im Kopf, ob ich das wirklich nutzen möchte.

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

Bisschen moderner Stil. Wir haben ja alle so einen gewissen Taste mittlerweile.

Ja, aber

wir sind gerade bei Dokumentation

gelandet, aber wir sind ja über Packaging

dahin gekommen und

ja, also okay, wir haben jetzt gesagt,

okay, Setup-Tools des Utils,

PIP,

es gibt noch irgendwie dann so bestimmte

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

oder ich habe gesehen, man kann sowas auch mit Poetry und

dann Pi-Project Hummel jetzt so ein bisschen basic

einrichten.

Ja, das ist doch mal...

Ja, also wie man jetzt zum Beispiel die Metadaten zu einem Paket ...

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

Ja, ja, also zum Beispiel so was Simples wie,

wie soll das Paket heißen?

Das muss man ja irgendwo hinschreiben.

Und da gibt es halt mehrere Methoden.

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

Also da ruft man halt Setup auf

und irgendwie die ganzen Parameter sind im Grunde alles

mehr oder weniger Argumente dieser Funktion.

Das ist sehr dynamisch und so. Da kann man natürlich tolle Sachen machen. Da kann man dann so Sachen reinschreiben, wie man holt sich die Version von dem Paket irgendwie aus irgendeiner Init-PY in dem Paket selber oder solche Sachen. Aber auf der anderen Seite macht das halt der Infrastruktur darunter, dass es sehr, sehr schwer ist, dass das so dynamisch ist.

Bei Project Hummel ist das ja auch ähnlich, es geht ja mit Poetry, wenn man damit arbeitet, auch so Bildbefehle und da kann man ja auch die Version direkt reinschreiben und einen kleinen Doxing reinschreiben und den Namen reinschreiben und so ein bisschen sich überlegen, was denn da stehen soll in dem Paket.

Ja, ich weiß jetzt gar nicht so ganz genau, wie das bei Poetry dann tatsächlich darunter funktioniert, also ich habe es schon benutzt, aber tatsächlich ist das für mich so ein bisschen eine Blackbox irgendwie, Poetry tut dann irgendwas und dann fällt ein Paket raus.

Also der Standardweg, wie man das mit Setup-Tools macht,

ist dann setup.cfg, wo man dann halt so statische Metadaten drin hat

und keine Setup-UI mehr verwendet.

Das ist auch das, was empfohlen wird.

Also die ganzen Leute, die sich da um dieses Python-Packaging-Ding kümmern,

die sagen alle, oh mein Gott, bitte, bitte, bitte verwendet setup.cfg,

das macht uns das Leben so viel einfacher.

Setup-UI ist für uns ein Riesenproblem eigentlich.

Also ich glaube, Setup-Chief-G ist viel

davon ist auch in PyProject-Hummel dann gewandert.

Genau, also PyProject-Hummel ist

mehr oder weniger ein neues Format dafür, ja.

Und das ist halt jetzt die aktuellste Art, wie man

die Metadaten sozusagen erfasst.

Und das ist halt auch Standard, ich glaube,

das ist PEP

518 oder sowas.

Irgendwie, glaube ich.

Ja, also das

wandert jetzt alles in PyProject-Hummel rein

und dann kann man das mit Poetry, wertet das dann halt

irgendwie aus und baut das dann. Ob Poetry

dann nochmal Setup-Tools unten drunter verwendet, weiß ich

jetzt ehrlich gesagt gar nicht. Aber es gibt dann auch

mehr Tools. Also

Poetry gibt es. Es gibt aber auch, ich glaube,

das habe ich in letzter Zeit

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

Oh, Flit?

Und es liest halt auch

PyProject Hummel aus

und baut halt Pakete.

Und vor allen Dingen benutzt es halt

nicht, glaube ich, nicht Setup-Tools, sondern

macht das alles selber. Und es benutzt auch nicht

Vine, um dann hinterher die Pakete hochzuladen,

sondern macht das auch selber. Das ist halt so eine komplett

integrierte Geschichte.

Was heißt flit? Das Symbol

ist ein Kolibri. Ich fragte mich, ob das auch flit

tut. Ich weiß jetzt

nicht, wo der Name herkommt. Keine Ahnung.

Also ein einfaches Modul, um Packages

auf PyPy zu bekommen.

Kenne ich auch noch nicht.

Klingt spannend. Ich habe es jetzt letztens

davon gehört,

also ich hatte schon mal vorher davon gehört, aber jetzt nochmal

ausführlicher in einer

Podcast-Episode irgendwie

Talk Python to me, wo, nee, nicht

Talk Python to me, haha, falsch. Test & Code, glaube

ich, von Brian Ocken

der hatte da Brad Cannon

zu Gast

und der halt

irgendwie da

halt auch für diese Pipe EA irgendwie

wesentlich zuständig ist und

ja, der sagte also

er benutzt auch selber Flit und das

wird ihm sehr gut gefallen, weil es halt einfach schnell

und so und macht das, was

es soll, während Poetry

ich verwende ja Poetry

normalerweise, aber ehrlich gesagt so manchmal

ich hatte das jetzt auch, ich glaube

in dem Stream, wo ich da so

Live-Sachen gerade irgendwie

entwickle, da

habe ich, ich habe dann

irgendwann mal das Virtual

N-Fax schmeißen müssen und dann habe ich

nochmal als irgendwie neu

von PyPI gezogen und

Pootree irgendwie Update gesagt oder Install, ich weiß es

gar nicht mehr genau und dann hat das irgendwie tatsächlich

geschlagene 300 Sekunden

irgendwie Dependencies aufgelöst.

Ja. So, wo ich dachte so.

Das passiert seitdem es das Async

macht. Ja, mir geht das

einstellen auf die Nerven. Da ist irgendwas richtig

kaputt, weil das darf nicht, also das kann

ich mir, ich kann mir nicht vorstellen,

wie das irgendwie, welchen

Grund es dafür geben könnte. Also ich meine,

ich weiß nicht, so viele

Pakete sind es nicht, vielleicht 50 oder so,

die da drin sind, Abhängigkeiten.

Und dass das dann irgendwie, also selbst

ein paar Sekunden wäre viel zu viel,

die Abhängigkeiten da aufzulösen. Wie kann das sein,

dass das 300 Sekunden braucht? Das ist irgendwie, irgendwas ist

da, oder es braucht

es halt irgendwie, wenn es ein Netzwerk macht, das kann natürlich

auch sein und PyPI überlastet ist oder so, vielleicht

würde PIP auch so lange brauchen.

Aber Pochi bringt ja einen eigenen Resolver mit und macht

das halt nicht über PIP. Aber offenbar

ist das irgendwie nicht so ganz okay. Also Pochi hat

mir schon so ein paar Mal

tatsächlich echt, ich dachte so,

okay, da ist irgendwas nicht

in Ordnung. Insofern...

Falls ich schon immer mal Open Source entwickeln wollte,

scheint es, als gibt es da ein paar Pull-Requests, die notwendig sind.

Keine Ahnung,

vielleicht muss ich mal reingucken, was da los ist, aber irgendwas,

also da kriege ich auf jeden Fall, wenn ich

sowas sehe, kriege ich einen Schreck.

Oh, das ist ein Tool, auf das ich mich verlasse und das macht komische

Dinge.

Und das hat auch so,

was mich auch bei Poetry so ein bisschen

wo ich auch dachte, ach, das ist nicht so schlimm,

aber das hat dann doch, macht auch

immer wieder Probleme, ist halt,

dass da halt, das gibt's bei den

Setup-Tools,

gibt's

Setup, man kann Python Setup

py-develop ausführen oder halt

pip-i

und damit halt so eine

editierbare Version von einem Paket installieren.

Das halt, wenn man das entwickelt, halt super praktisch ist.

Und das geht mit Poetry

geht das nicht. Also geht

einfach gar nicht. Und was meinst du mit

editierbare Version installieren? Also das lädt quasi

seine lokale Datei

als Symbolink

Ja, ja, ja, genau.

Es ist nur in den, tatsächlich

im Virtual Env landet dann halt nur so eine Art Link

und sobald man den Code ändert,

dann muss man halt nicht irgendwie

nochmal neu das Paket installieren, sondern

sondern die geänderte Version vom Code ist dann halt direkt da.

Das ist tatsächlich ein ganz, ganz wichtiger Punkt,

den ich auch lernen musste.

Wenn man mit einem Package arbeitet, dann denkt man erst mal,

ja, cool, du hast ja meist den Code irgendwo,

oder oft fängt man ja an, dass man denkt,

ah, ich habe jetzt was gebaut in meinem Projekt,

ich würde das gerne irgendwie generalisieren

oder vielleicht anderen Leuten zur Verfügung stellen,

was auch immer die Motivation sein könnte.

Und dann merkt man, ja gut, jetzt habe ich das,

jetzt muss ich es ein bisschen anpassen.

Ja, wie teste ich das denn jetzt?

Das ist ja jetzt ein eigenes Projekt,

das ist ja jetzt nicht Standalone,

das ist ja kein Django-Projekt in meiner Welt.

Was macht man denn dann?

Also dieses pip-e, das ist tatsächlich sehr, sehr cool und sehr einfach.

Also ich nutze in den meisten Projekten pipenv einfach, weil, ja, weil.

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

Nö, weiß ich nicht.

Naja, auf jeden Fall, ich bügele das dann halt einfach dann nochmal,

also alles mit pipenv installiert und so und dann einfach manuell nochmal mit pip

dann das drüber bügeln, um diesen Sim-Link zu machen.

Und damit kann man dann sehr, sehr entspannt und sehr cool,

dann auch mit zwei verschiedenen IDEs einfach.

Auch im einen ändert man halt dann

das Package erstmal gerade oder den

Source Code des Packages, im anderen hast du quasi

deinen richtigen Django-Web-Server

oder was auch immer dein Projekt macht.

Und das ist sehr, sehr

convenient und da muss man auch erstmal wissen, was man suchen muss.

Also du

hast auch schon mal so ein paar Pakete gebaut, ich glaube

auch, das hast du auch bei GitHub hochgestellt.

Genau, ja, ich habe

vor ein paar Jahren die

Ownership von dem Package

oder Maintainership von dem Package

übernommen. Das

habe ich auch schon mehrfach am Rande mal erwähnt

auf ein paar Blog-Einträgen und sowas. Das ist dieses

wunderbare AI Django Core Package.

Das

ist entstanden aus,

wir hatten in der Frühzeit unsere

Geschichte, also bei AIM Innovation, deshalb AI,

hat nichts mit künstlicher Intelligenz zu tun,

etwas misleading,

haben wir

gemerkt, dass wir halt irgendwie ganz praktische Sachen gebaut

haben und dass man die halt irgendwie immer vom Projekt zu Projekt

kopieren ist doof. Und

da so, ja, machen wir mal ein Package und dann

ist es halt einfacher zu installieren.

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

und dann ist dann halt die Jahre...

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

okay, den Code nehme ich jetzt immer mit und hab die Basis-Funktionalität

dann... Genau, ohne dass man es halt kopieren muss und

hat halt dann keine Code-Renundanzen und sowas. Und wie gesagt,

wenn man mal einen Bug fixen möchte oder irgendwas... Ja, vor allem, das ist halt

blöd, wenn man halt irgendwas weiterentwickelt, ein neues Feature, und dann

muss man das in jedem einzelnen Projekt wieder nachbauen,

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

Genau, und dann haben wir uns dann,

dann ist da halt über Jahre

dann so Einbahnstraßen-mäßig da halt Code hineingeflossen, auch dann irgendwie gab es dann irgendwann mal diesen großen Break, wo dann wirklich alle von Python 2 weg sind und dann waren da noch Python 2 Sachen drin, Python 3 Sachen und dann irgendwann habe ich mir das mal zur Brust genommen, ich glaube das war so 2018 ungefähr, habe ich mal angefangen zu gucken, was ist da eigentlich drin, weil ich da selber

aber auch ziemlich viel contributed habe, weil ich halt

oft Sachen gebaut habe, wo ich dachte, ach, das ist cool,

das würde ich im nächsten Projekt auch gerne nutzen.

Oder das, keine Ahnung, zum Beispiel Richtung

Test-Setup oder so Sachen, die einfach

das Ganze ein bisschen streamlinen und ein bisschen

mehr so machen, wie ich das für richtig halte.

Dann habe ich irgendwann mal angefangen zu gucken, was ist denn da eigentlich

alles drin? Und wie gesagt, da waren Kompatibilitätsprobleme

und da war anfangs noch kein

Linting drin und die Dokumentation, es war nichts

dokumentiert, es gab keine Dock-Strings,

es gab überhaupt keine Art von Dokumentation,

also es war auch einfach nichts,

also man wusste halt, was drin ist oder man hat

halt im Code rumgesucht, aber war halt irgendwie

überhaupt nicht wirklich irgendwie

freundlich und in dem Zuge, dass ich halt

dann angefangen habe, ein paar Blogartikel zu schreiben, weil ich das

auch irgendwie ganz cool fand, weil ich dachte, hey, wenn ich das Problem

mal gelöst habe, das interessiert vielleicht auch jemand anders,

dachte ich, ja gut, das ist halt irgendwie, ich kann

da zwar einen Artikel drüber schreiben, aber eigentlich ist das

so ein bisschen eine Frechheit, wenn man das so lässt, weil das

halt nie, also in dem Zustand eigentlich nicht dafür da war,

dass man das wirklich nach außen irgendwie gibt.

Und das habe ich über die letzten Jahre halt dann angefangen

und habe dann da in verschiedenen Wellen

und Steps, ja,

was gemacht. Also zum Beispiel

super wichtig für mich,

oder ein super wichtiges Learning für mich war, dass man einen Change-Log

macht, allein schon für einen selbst.

Ich habe keine Ahnung, was ich vor,

also ich mache ungefähr

alle ein bis zwei Monate einen Release,

also irgendeine Art von Release. Kann mal

Mad-Release sein, wenn ich irgendwas Größeres

wirklich rudimentär gemacht habe oder halt

was Kleineres, aber so ein bis zwei

Monate, das heißt, da kommen einige Releases zusammen

über die Zeit und wenn man dann

mal irgendein größeres Projekt

hat und das hochziehen möchte und denkt, ja komm, ich brauche

ist dieses neue Feature, das da drin ist, und man nicht

weiß, was man seitdem denn alles geändert hat

und nicht weiß, wie man dann sein Projekt,

dass man das aktualisieren möchte, wie man das möglicherweise

kaputt macht, das ist echt blöd.

Aber das geht ja dann auch direkt Richtung,

wie vergibt man Versionsnummern und was ist,

da gibt es ja auch... Ja, genau, da sind wir ja, genau.

Semantic Versioning, glaube ich, habe ich gehört, ist da

en vogue.

Macht man das noch?

Ja, naja, nicht, also ich wusste es halt...

Wie man lustig ist?

Ich guck mal...

Ich habe gerade

einen Artikel,

Semantic Versioning

won't save you.

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

rausbringt, so von 2 auf 3 oder sowas,

dann gehen Dinge kaputt. Das sind wir ja vielleicht nicht.

Ja, also genau, da gibt es

einen sehr schönen Blog-Artikel von

Hüneck,

Hüneck, Schlaback,

Semantic Versioning will not save you.

Der ist auch jetzt, genau,

der ist von Anfang März,

den habe ich mich nicht erinnert. Ja, leider

ist das auch alles, also ich meine, es ist vielleicht besser als

nix, aber es ist halt, es ist alles

irgendwie. Vielleicht, was ist das denn?

Was ist denn Semantik-Versioning? Was macht man denn da?

Naja, dass man

sozusagen so ein bisschen,

also nicht nur das hochzählt,

sonst könnte man ja einfach nur noch eine Zahl hochzählen,

sondern dass da halt eine Bedeutung dran hängt,

dass man zum Beispiel so eine Dreiteilung hat.

Macht man bei Setup-Tools auch oft so,

dass man da irgendwie dann Tuples verwendet, damit das

klar ist, welche. Und dann wird es halt

dann oft hat man dann halt irgendwie Major

Version Punkt Minor Punkt irgendwie

Patch Release oder so.

Und in den Patch Releases

sollten halt nur Bugs gefixt sein. Minor

sollte vielleicht kommen, vielleicht

Features dazu, aber es wird die

Abwärtskompatibilität nicht gebrochen und dann

bei Major Versionen kann man halt irgendwie

eine neue App benutzen oder sowas.

Ja, kann man es halt inkompatibel machen.

Und oft sieht man das dann auch, dass Leute

das dann halt in, ja,

wenn sie halt ihre Abhängigkeiten definieren, dann so

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

größer gleich dieser meiner Version

zum Beispiel, sodass halt sie

keine Updates oder Features noch

bekommen oder halt alle Security-Patches, aber

halt nicht, dass die Kompatibilität

nicht gebrochen wird.

Nur das Problem ist natürlich, dass

tatsächlich garantiert ist halt auch ein Bugfix

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

darauf verlassen hat, dass sich etwas so verhält, wie es

jetzt halt tut und das aber ein Bug war.

Ja, das ist natürlich insofern

ja, aber

bei 0.9.7.0.20, das ist auch super.

Ja, das gab ein sehr schönes Beispiel, das war vor, ich glaube, einem Jahr, vielleicht eineinhalb Jahren, zwei Jahren, da hatte Flake 8 ein neues Patch-Release rausgebracht, also die haben ja, glaube ich, von 0.96 auf 0.97 oder sowas und haben da aber einen neuen Check eingebaut, der nämlich gecheckt hat, ob F-Strings Variablen enthalten.

Und wenn du dann S-String oder Variablen hast,

dann ist es rausgeflogen.

Und plötzlich sind halt dann bei diversen Projekten

geht die Pipeline nicht mehr.

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

War halt mit Star-Import einfach im PIP-File.

Und ja, blöd.

Tja.

Wie gesagt, vielleicht hätte das schon vorher

das überprüfen sollen, aber es war halt ein Bug

und hat nicht funktioniert.

Haben die den Bug repariert

und schon hast du auf einmal ein komplett anderes Ergebnis

und plötzlich ein Breaking-Change in deiner Pipeline.

Aber trotzdem.

Ja, dafür ist dann

Pult wieder ganz ruhig, wegen der Log-File,

wo es halt dann genau die Dependencies print.

Ja, ja, auch eben, weil

falls halt irgendwie

andere Dinge, also einfach um

reproduzierbare Umgebungen zu bekommen

und auch wenn jemand es schafft,

irgendwie malicious Pakete

irgendwo hinzulegen, das ist ja auch so etwas,

was dann zumindest sehr überprüft wird,

dass der Hash stimmt und so, ja.

Er würde dich auch nicht davor retten,

wenn da schon ein malicious Paket drin wäre.

Nee, dann hast du schon verloren, genau.

wenn es halt jemand später schafft, genau.

Aber tatsächlich bin ich

jetzt auch ein großer Freund, dass ich

eigentlich alle Abhängigkeiten, die ich habe,

wirklich fixiere, weil ich bin da schon zu oft

auf die Nase gefallen mit,

weiß ich nicht, irgendwie Celery,

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

die haben im Bugfix-Release irgendwie

ein Attribut deprecated und rausgenommen

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

und das komplette Async ist tot.

Und das ist halt bitter.

Ja, ist schon doof.

Ich habe gerade ein Problem mit

auch einer Pipeline,

weil das irgendwie so doof

gebaut wird, dass da Abhängigkeiten zu Docker

drin sind, dass aber das System

dann doch abhängig funktionieren muss. Also das heißt,

die nehmen dann, weil wir auf einer Windows-Maschine das aufbauen

müssen, PyWin mit rein

und das installiert sich natürlich nicht auf

der Windows-Maschine, weil das dann in den Dependencies

mit drin hängt. Das heißt, ich muss in der Pipeline das Log-File

wegschmeißen. Toll.

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

Verlassen, dass dann halt das Dependency-Resolving

vernünftig funktioniert, aber

naja, da muss man halt doch wieder dann manuell pinnen.

aber das geht dann schon irgendwie.

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

Da gibt es keine richtig gute Lösung für.

Also wie baut man denn jetzt Python so zusammen,

dass es immer vernünftig funktioniert,

immer wieder auch in zwei Jahren noch irgendwo

und das ist ein bisschen blöd irgendwie.

Also auch wenn man jetzt,

ich nehme jetzt noch dieses Windows-Beispiel,

wenn man jetzt eine Executable erzeugen möchte,

den man Leuten gibt, die eigentlich gar kein Python können

oder auch programmieren nicht können oder sowas,

sondern die wollen einfach ein Programm haben,

was sie ausführen können, was dann auf Python läuft

und bestimmte Dinge tut. Das

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

Aber darum gibt es ja auch Web-Software.

Das ist ja genau der Grund, dass man diesen Knatsch halt

nicht mehr hat. Ja gut, aber es gibt ja auch

da verschiedenste Lösungen, wie man irgendwie so ein großes

Paket zusammenschnürt, wo man dann alles

mit reinpackt und

die Dependencies mit reinpackt und den Compiler mit reinpackt

und so, dass das dann halt selbstständig

irgendwie aufgebaut werden kann. Ja, kann man

schon. Also ich meine, PyInstaller ist halt wahrscheinlich

vielleicht so die populärste. Es gab

ja einige. Nuka. Es gab dann

Nuka, PyOxidizer. Wir

hatten da ja auch schon ein paar Mal drüber.

Inzwischen, wenn man auf die Tools guckt,

das sind Pi-Oxidizer und so, das ist schon wieder

alles verschwunden aus den Empfehlungen.

Das hat sich wohl

dann... Pi-Installer ist irgendwie

erstaunlich konstant.

Ich habe es noch nie richtig... Funktioniert einfach

nicht so, wie man will, wenn man zu viele externe Dependencies

hat. Das ist auch nicht schön.

Ja.

Kein einfaches Problem,

leider.

Ja, aber was macht man da? Also Paket

bauen? Ja, du sagst Web-Anwendung.

Ja, Web-Anwendung, oder ich meine, klar,

Docker-Image dürfte schon relativ haltbar

sein, ist auch, ist natürlich so ein bisschen

verschwenderisch groß alles. Solange es

Docker noch gibt, ne? Ja.

Ja.

Aber, tja,

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

Meine Lösung ist,

nicht auf Systemen unterwegs sein, wo das ein Problem ist.

Gut, aber es gibt halt

Leute, die halt andere Systeme nutzen, das ist ja klar.

Ja, ich verstehe das. Wenn die darauf relien,

und wenn man von bestimmten Konzernen,

die halt dann bestimmte Policies haben, die man nicht

verstehen muss, aber wo man das natürlich daran halten muss.

Die haben bestimmt 1998 Sinn

gemacht, dass die jemand eingeführt hat.

Ja, also die sind auch veränderungsresistent,

da würde ja die ganze Abteilung sich als Renonant

erweisen vielleicht, aber

solange die gut verdienen, ist das halt nicht notwendig

da irgendwas zu ändern, das ist halt

dann so.

Ja, aber wie gesagt, also

nochmal zur Versionierung zurück,

ich mache tatsächlich auch die Semantic Versioning,

man kann halt damit wenigstens versuchen,

dass man halt dem

Nutzer, den man ja meistens nicht kennt, so ein bisschen

wenn die, ja, den Pain

zu nehmen, wenn man halt, wie man mit Updates umgeht,

weil jedes Update, je nachdem, wie groß das Projekt ist und

auch, wie stabil das Projekt ist, so

Stichwort Testing und sowas,

kann das ja auch ziemlich, mit ziemlich

viel Kopfzerbrechen verbunden sein, irgendwas

überhaupt hochzuziehen und

bei dem habe ich jetzt halt gesagt, hey, wir

machen jetzt Semantic Versioning und da

versuche ich mich auch sehr dran zu halten, also

darum habe ich jetzt auch schon in den Jahren jetzt

vier Major Releases gemacht, weil

Python hat irgendwie komplett

alles auf drei umgestellt, ist halt ein Breaking Change,

musst du halt hochgehen, da kommst du halt nicht drum rum.

Fühlt sich manchmal so ein bisschen verschwenderisch an,

wenn man denkt, schon wieder, das ist

nicht so viel Code, aber

man kann halt einfach nur hoffen, dass man

es den Leuten halt möglichst einfach macht, weil

das Problem ist, da sitzt dann nachher am

anderen Ende der Welt jemand, der möchte genau das Package

verwenden oder nutzt es im schlimmsten Fall vielleicht schon

und dann macht man ihm plötzlich was kaputt, der hat keine Chance

irgendwie vernünftig zu erreichen, zumindest

nicht direkt und

da sollte man ja schon

gucken, dass man das

ja, so stabil wie möglich baut.

Ja.

Ja, ja.

Ja, ist auf jeden Fall nett.

Ja, also ich wollte gerade sagen, also

ich glaube, manchmal machen die Leute auch so ein bisschen zu viel

Schwurbel um, es muss

backwards kompatibel sein für

bis in alle Zeiten.

Absolut. Ich finde es vollkommen okay zu sagen,

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

Aber die müssen es halt wissen.

So, ich meine, wäre halt einfach...

Ja, es wäre schon nett, wenn man halt die Versionsnummer dann vielleicht major ändert.

Genau, also wenn jemand halt blind irgendwie drei Majors hochgeht

und sich dann ärgert, dass es nicht geht, ja gut.

Wie gesagt, ich meine, manche Projekte haben ja leider wirklich kein Change-Log

oder so ein ganz rudimentäres.

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

Wie machst du das Change-Log und wie schreibst du das dann auf?

Schreibst du dann vor jedem Commit

oder lässt du aus den Commit-Messages automatisch dein Log kriegen?

Ich mache das tatsächlich zu Fuß.

Also da gibt es ganz viele Tools.

Ich fand das Stand irgendwie nicht dafür,

weil wie gesagt, wenn ich irgendwas mache,

dann weiß ich ja, was ich mache

und dann kann ich es auch einfach kurz ins Change-Logger.

Das ist einfach ein Markdown-File.

Disziplin, vernünftig deine Arbeit zu dokumentieren.

Ja, und vor allem, das sind ja auch Stichpunkte.

Ich meine, inzwischen habe ich eine Dokumentation,

da kann ich gleich noch was dazu sagen.

Auch ein Thema für sich.

Aber ich habe einfach ein Markdown-File

und das ist halt eine lange Liste, wo dann halt drinsteht,

hey, am so und sovielten habe ich diese Version released

und das hat sich geändert.

Ich habe da irgendwie, weiß ich, drei Rechtschreibfehler

in der Dokumentation gefixt, die Funktion ist neu

und die Funktion hat neun Parameter.

So, und dann, das ist halt, das dauert eine Minute, das zu schreiben. Ich meine, ich weiß ja, was ich da tue. Und wenn ich jetzt sage, ich sammle ein paar Kleinigkeiten, wo es sich nicht lohnt, ein Release zu machen, weil ich es gerade nicht so dringend brauche, dann habe ich halt einfach so ein current, temporäres Ding oben drin stehen und dann, wenn ich halt fertig bin, dann sage ich, okay, das gebe ich dem Namen, also sprich eine Versionsnummer und dann habe ich die Sachen einfach schon zusammengeschrieben, wenn von mehreren Seiten was, oder wenn mal auch von Kollegen oder so ein Pull-Request reinkommt oder sowas.

Das ist auf jeden Fall ordentlich.

Also ich tatsächlich

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

hatte, dass ich denke, ja kacke, kann ich das jetzt noch

verwenden, kann ich es nicht verwenden so.

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

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

Entwicklung jetzt damit noch nicht anfangen, Change.org zu schreiben,

wenn ich jetzt noch nichts habe, was richtig fertig ist und was

funktioniert. Wahrscheinlich bei Person 1.0

würde ich auch. Irgendwie so, ne, ja.

Oder sobald halt Leute anfangen, das zu

verwenden irgendwie. Was du natürlich auch nicht so genau

weißt, also. Ne. Ja, sobald

du was einigermaßen Nutzbares irgendwie hast,

vielleicht. Ja. Genau.

Ja, ich überlege gerade, ob ich was nicht so mache und denke mir so, oh nein, ich breche trauernd die Komplimente.

Ich meine, es kommt auch immer darauf an, wenn das halt so ein Mini-Ding ist, also gut, selbst das kann irgendwie an eine zentrale Stelle eingebunden sein, aber zum Beispiel jetzt das Package, an dem ich jetzt arbeite, das ist halt eigentlich, das ist halt so eine Toolbox.

Und ich bin eigentlich gar kein großer Fan, dass man so diese, sagt, hey, hier ist so ein Haufen von Zeug, das du so querbeet in dein Projekt einsetzen kannst.

Wie so der Werkzeugkoffer bei euch im Schrank. Da hängt auch alle möglichen Schraubenschlüssel rum. Jeder hat seinen eigenen Werkzeugkoffer mit eigenen Schraubenschlüsseln. Tauscht man zu selten aus. Und da sind aber die Farben, die hat man sich selber zusammengesucht und man weiß selber, wo man in der Kiste was findet. Aber wenn jemand anders da in diesen Werkzeugkoffer reinguckt, dann, ja.

Genau, also ich finde es eigentlich cooler, wenn man das, ich meine, da muss es nicht auf JavaScript-Level gehen, wo die quasi jeder zwei Zeilen ein eigenes Package ist, das ist manchmal ein bisschen krass, aber wenn man die Sachen vielleicht auch ein bisschen, also sagt man so, würde ich jetzt das Package nicht geerbt haben, sondern würde es jetzt neu machen, dann würde man sagen, hier dieser Code, der soll irgendwie Packages, würde ich das wahrscheinlich nach gewissen Use Cases strukturieren.

Also auch nicht mehr Core nennen, sondern tatsächlich den Funktionalitätsgebiet.

Das ist ja auch so ein Klassiker, das haben ganz

viele Firmen. Ganz viele Firmen haben ein Paket, das

heißt so wie die Firma. Oder

sie haben halt ein Paket, das heißt dann irgendwie wie die Firma

plus Core oder das heißt halt Core

oder so. Das ist

ja, das ist ganz, ganz typisch.

Aber wie gesagt, zum Beispiel

ich habe irgendwie ganz viele Sachen gebaut, die mir bei Unit-Tests

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

das Ambient-Unit-Test-Paket

oder so. Und dann alle Sachen, die haben irgendwas

berechnen oder die irgendwas mit dem View-Layer

zu tun haben, weil viele Projekte laufen bei Django inzwischen

auch Headless so, das hat dann auch gewisse

Dependencies, die man ja sonst nicht reinholen muss.

Das ist dann auch

ein eigenes Paket. Und ich habe das jetzt mit

Extensions tatsächlich gemacht, weil am Anfang

war es auch so, dass auch die ganzen

Dependencies wurden alle mit installiert immer,

weil damals mir gar nicht so bewusst war,

dass man das irgendwie trennen kann. Ich habe das dann einfach irgendwann übernommen

und so ein bisschen umstrukturiert und dachte, okay, cool,

funktioniert, wird schon passen. Aber man

kann tatsächlich sagen, dass man verschiedene

Extensions macht. Also das kennt man, wenn man das

aus dem Requirements oder so

ist, so eine enge Klammer, wo dann irgendwie

bei Celery kann man es mit SQS oder

mit Revit oder keine Ahnung welchen Extensions installieren

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

die Dependencies wegkapseln, weil du kannst zum Beispiel

sagen, hey, also zum Beispiel in meinem Fall

ist es jetzt, ich habe diverse Sachen, die halt

nur fürs Django Template Layer interessant sind,

also ein Middleware und sowas und da sind halt

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

Das heißt, ich kann einfach hingehen

und sagen, hey Leute, also steht es dokumentiert

und sage, hey Leute, das ist das Standardpaket,

das ist so das normale Shit, den man so mit Django

machen kann und wenn

ihr jetzt irgendwas Spezielles Julia haben wollt,

das ist hier dokumentiert und da müsst ihr

halt noch die Extension mit installieren und dann

kriegen die halt auch die

Dependency.

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

direkt das volle Rundum-Sorglos-Paket an,

dass die ja nicht so viel Aufwand haben und das alles lesen müssen

und alles nachinstallieren müssen oder

machen wir das halt sehr modular?

Also ich sag mal so,

du kannst ja theoretisch

auch einfach alles installieren, wenn du es willst.

Das ist relativ zentral. Steht das auch am Anfang, hey, das gibt es

und wenn du nicht so genau weißt, dann kannst du einfach alles nehmen.

Aber ich finde es halt schön den Leuten, die halt

mehr Kontrolle haben wollen, die zum Beispiel sagen wollen,

hey, ich achte drauf, welche Unterdependencies

in mein Projekt reinkommen, weil ich halt keinen Knatsch

haben möchte oder sowas.

Denen halt die Möglichkeit zu geben. Und dann auch

ganz wichtig, dass man die ganzen

Build-Dependencies, die man

wirklich nur auf Meta-Ebene,

also wenn du am Package arbeitest, dass man die halt

rausnimmt, weil das bringt halt unendlich viele Sachen

sonst nachher in so ein Projekt rein, den man eigentlich gar nicht haben

möchte. Genau, ich habe

jetzt hier gerade nochmal

das letzte Paket, das ich irgendwie

gebaut hat und reingeguckt.

Das ist Django Fire Response.

Oh, da hast du auch in deinem Stream

einiges dran gearbeitet. Genau, da habe ich

jetzt, bis letzte Woche habe ich da noch was dran gemacht.

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

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

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

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

wie man das live macht. Ja.

Ich finde es eigentlich, es sieht cool aus.

Und ja, wirklich.

Danke, danke, danke. Genau.

Ja, technisch gar nicht so schlecht, glaube ich.

Inhaltlich muss ich noch ein bisschen feilen, glaube ich.

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

sehr spannend ist, was man da alles so umsetzen kann.

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

Ich habe... Also Final Responses fand ich

sehr interessant, den möchte ich auch mal bauen, ja.

Also wo ich tatsächlich noch Schwierigkeiten... Ich merke das, das habe ich

heute wieder gemerkt, tatsächlich,

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

nicht erwartet hätte, also wenn ich

irgendwie so an den Projekten rumentwickle und

ich weiß aber, das können sich

Leute nachher angucken, dann tendiere ich

dazu zu sagen so, ah, jetzt gut,

jetzt müsste ich da jetzt immer tief graben oder

irgendwie versuchen rauszukriegen, das wird voll langweilig

und ich muss ganz viel probieren. Und ich habe absolut keine Ahnung,

ob ich damit irgendwie in einer halben Stunde fertig bin oder so.

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

fürchterlich langweilen.

Und es ist fruchtlos.

Also das merken, weil normalerweise

würde mir das halt nichts ausmachen. Mir macht das ja Spaß,

das zu entwickeln. Und dann probiere ich halt rum

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

Ich muss sagen, also mir macht das auch Spaß, weil dieses

Rumprobieren, das kriege ich dann ja mit.

Und da lerne ich auch mal was bei. Und ich glaube, gerade dann, wenn man

halt nicht alles so perfekt vorher schon weiß,

sondern das so ein bisschen rausknobeln muss.

Und man ist ja quasi mit live dabei. Das ist ein bisschen

vielleicht wie am Podcast, durch dieses Rausknobeln,

das du ja dann machst, dann knobelt man selber

so ein bisschen rein und man kommt halt tiefer

in die Thematik rein und man hat ein tieferes Verständnis

für die Zusammenhänge und das ist unheimlich

wertvoll dann. Deswegen sollte man sowas, glaube ich,

tun, ja. Ja, das ist tatsächlich vielleicht eine interessante

Geschichte, dass man genau da bei Leuten

halt so, aber wenn man das macht oder

für mich war das überraschenderweise so,

dass ich das Gefühl habe, oh, jetzt muss ich aber weiter

oder oh, da sehen Leute, dass ich keine Ahnung

habe oder weiß ich nicht, irgendwie so ein

Ego-Ding, dass ich nicht so

richtig los werde und da ist mir jetzt schon ein paar Mal

aufgefallen, okay, da habe ich dann irgendwas übersprungen oder

dann bin ich nicht so, mache ich das nicht so, wie ich das normalerweise

machen würde. Also ich weiß eine Lösung.

Also du hast ja so ein tolles Pult,

da kannst du so bestimmte Einwendungen machen. Ich würde so

einen Button dann einfügen, den kannst du zumindest später

runterschalten, wo dann einfach so fett zensort auf dem

Bildschirm steht, so ein schwarzer Balken,

dann wird das, was du gerade programmierst, einfach kurz sensiert und

der Ton gestrambelt, dann gehst du so

selber kurz draufdrücken, dann hast du einen

kurzen sensierten Teil, dann kannst du

wieder freischalten, dann, okay, geht wieder.

Ja, genau,

wird sich schon irgendeine Methode finden.

Kennt ihr das aus Starship Troopers, wo es dann kurz diesen

Send-Out-Biken gibt und in den Hintergrund werden die Kühe dann von den Elfen vergessen?

Ja, und hinten wie so die Gedärme fliegen, genau.

Ja, das stimmt.

Das ist eine gute Idee.

Da fliegen noch nicht genug Gedärme

in dem Stream, das ist wahr.

Genau, da habe ich ja dieses

Django-Fire-Response-Paket gebaut.

Da habe ich etwas verwendet, was ich jetzt vielleicht dann

auch nur aus Spaß

habe ich

ein MBDev, was in der Data Science

welther so ein bisschen

verbreiteter ist. Vielleicht nochmal ganz kurz, das hast du auch schon

einmal kurz erklärt, aber NBDEF ist quasi

entwickeln mit dem Notebook, aber das Notebook quasi

das bei dem Paket automatisch

mit den Dokumentationen und so erzeugen kann. Genau,

also das eigentliche Ding, was das so interessant

macht, ist, dass man so ein bisschen Literate Programming

machen kann und halt

Dokumentation, Code und

Tests irgendwie direkt zusammenstehen hat

und daraus dann halt sozusagen

aus den Notebooks wird dann das Paket

erzeugt oder das Modul, also der

Source-Code erzeugt

und aus dem

Source Code wird dann ein Paket gebaut und das

geht auch tatsächlich, ich habe jetzt nochmal nachgeguckt, weil ich es gar nicht mehr wusste,

aber ja, das macht das per Setup.py

und da hat man halt auch

eben, da

schreibt man halt rein, extra

Extras Require zum Beispiel

und kann dann

halt, das ist einfach nur ein Dikt und

dann kann man da beliebige Dinge reinschreiben, halt zum Beispiel

was ich jetzt da nur drin stehen habe, ist halt Dev und dann

Dev Requirements, aber man kann halt auch eben

eben alle möglichen optionalen Geschichten mit

angeben, die man dann halt installiert oder nicht und

da wäre es zum Beispiel so, also dieses

Django-File-Disponse-Dings hat selber praktisch keine

Abhängigkeiten,

aber wenn ich jetzt

die Dev-Requirements da mit reinnehmen würde,

dann wäre das ziemlich übel, weil dann würde

der ganze Envy-Dev-Kram mitkommen zum Beispiel.

Es würden Jupiter-Notebooks mitkommen,

es würde Pandas mitkommen, es würde Nam-Pi mitkommen,

es würde irgendwie so das

halbe Deadline-Universum

mitkommen, was du normalerweise

auf dem Web-Server hast, wo du Django

verwenden willst, hast du es ja gar nicht. Und plötzlich

wird dann wahrscheinlich irgendjemand

vor einer Konsole sitzen und denken sich,

warum kommt da jetzt ein Fortran-Compiler

mit Telefon drin? Und warum dauert

das eine halbe Stunde, bis das kompiliert ist?

Ja, genau.

Nicht so gut.

Aber vielleicht noch mal kurz zur NBDEV.

Wie baut man denn quasi sein normales Notebook

in ein NBDEV um, damit es halt dann auch als Paket

nutzbar ist?

Muss ich da quasi ein anderes Notebook nehmen

oder kann ich einfach ein Jupyter-Notebook nehmen?

Das ist ein Jupyter-Notebook, aber das Einzige,

was man da braucht, ist im Grunde

man muss MBDev installieren

und dann halt MBDev build lib

und dann hat man so ein paar Metaanweisungen

sozusagen für MBDev in dem Notebook selber.

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

und wo man dann quasi ein bisschen anders strukturiert,

als man nach vorne machen würde?

Nee, das ist keine Extension,

sondern das liest es einfach nur.

Und wenn man da sowas reinschreibt wie Kommentar

und dann Export oder Default Export,

also diese Sachen werden dann ausgewertet

und werden dann benutzt,

um dann daraus zum Beispiel die Python-Module zu erzeugen.

Also es ist nicht mal irgendwie

ein Jupyter-Plugin

oder sowas. Das heißt, man muss einfach richtig

seine Zellen vom Typ her definieren im Jupyter-Notebook

und dann Docs hinschreiben.

Dann wird das gelesen von der MBDF und das schreibt dann halt

den Source-Code dann raus.

Also ich fand's eigentlich ganz nett.

Ich find's auch sehr spannend, also sehr cool.

Ich benutze auch relativ viele Notebooks zum Entwickeln.

Also gerade auch so Django, so I.O. Sachen oder sowas

oder Modellsachen, Funktionen, Methoden.

Die kann man einfach super schnell

dann testen. Die gehen halt an, Django-Shell auf

und dann kann man testen.

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

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

ich mache das tatsächlich so, dass

ich das öfters ich oft mit dem Debugger

entwickle. Ja, das ist auch eine interessante Option.

Ja, auf jeden Fall. Das mache ich

nicht so oft, aber das wollte ich mir auf jeden Fall

auch nochmal angucken. Du nützt ja auch

PyCharm, ne? Das ist, glaube ich,

sehr komfortabel. Ja.

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

Ja. Weil dann speichert ihr die Datei

und dann fliegt der Debugger raus. Ja. Aber

ich finde, das ist eigentlich ganz cool.

Also vor allem, wenn man so viele Funktionen

und so irgendwie externen Daten und sowas bekommt,

wo man dann oft irgendwie,

okay, da muss ich mir auf die dritte Area-Stelle zugreifen.

Das sind Sachen, die man halt, du weißt, es ist da irgendwo,

du weißt nicht genau, wo es ist.

Und da macht man dann normalerweise viele Runden

und das ist dann einfach angenehm,

wenn du dann direkt einfach in diesem Evaluate-Expression

einfach die Sachen da zusammenklopfst

und dann direkt auf den Knopf drückst und weißt,

jo, läuft, passt, nice.

Ja, da muss ich auch wieder ein Land zerbrechen,

das geht auch in anderen Entwicklungsumgebungen

tatsächlich ganz gut, wenn man die richtig einstellt.

Das haben wir so ein bisschen gefummelt,

bis man halt den Debugger so laufen hat,

wie man das gehen hätte.

Aber hast du da schon diesen Debugger,

den wir letztes Mal vorgestellt haben, gesehen?

Und zwar Kodo, oder wie hieß der?

Kodo-App?

Kodo-App, genau.

Das ist ein neuer Django-Debugger,

der relativ coole Sachen machen kann,

wie Visualisierung der Code-Pathes und sowas.

Cool.

Relativ geil, musst du mal schauen.

Ist aber nicht für Python.

Ja.

Ja, aber das wäre auch auf jeden Fall, genau.

Also das habe ich mir auch zum Ziel gesetzt.

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

Aber das eben jetzt mal explizit nicht zu machen,

sondern im Stream halt versuche ich jetzt,

zum Beispiel habe ich jetzt immer eher VS Code benutzt.

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

Oder halt auch PyCharm würde ich auch auf jeden Fall machen.

Ja, also ach so, was du auch noch dabei machen solltest,

vielleicht ist so ein bisschen so die Konfiguration zeigen,

ein bisschen so die Magie zeigen, wie man das Tool dann jeweils benutzt.

Das ist, glaube ich, auch noch mal sehr lehrreich.

Also vielleicht kurz darauf eingehst,

so wie man es da so nachmacht.

Kann ich mir einfach mal vornehmen, das zu versuchen zu verwenden.

weil dann, also je mehr man halt neue Sachen

lernt, die man noch nicht lernt.

Ja, okay, ich werde es mal versuchen.

Ja, ja.

Ja, das ist schon richtig.

Man muss einfach ab und zu mal Dinge ausprobieren, das ist

ganz wichtig.

Ja, wenn man sonst immer noch bei seinen Sachen bleibt, dann wird man darin

auch ein bisschen besser, aber was neue Sachen ist, ist schon spannend.

Ja, ja, oft. So was wie Programmieren oder

sowas kann ja auch für einige Leute neu sein.

Ja, eigentlich bin ich schon fast

zu lange dafür dabei, um das so noch zu erzählen.

Aber ja, ist noch wahr.

Das Gefühl geht auch nicht weg.

Ja, okay.

Ja, man hat halt von allen Sachen immer keine Ahnung.

Aber irgendwie hat man dann doch mehr Ahnung hinterher,

so Rückblicken von einigen Sachen,

die man eigentlich gar nicht wissen wollte.

Aber so da vorne ist immer,

der Berg wird immer größer anstatt kleiner.

Das ist so ein bisschen das Problem.

Ja, weiß nicht, was mir bei so zunehmender Erfahrung auffällt,

ist oft,

muss ich gar nicht mehr so

oder was mir heute leichter fällt

oder ich sag mal so, der Unterschied zwischen heute und

den Zeiten, wo ich halt wenig Erfahrung

hatte, war halt, ich hatte früher immer mehr

das Gefühl, bewusst Dinge zu tun oder

bewusst irgendwie Sachen auszuprobieren. Und heute

muss ich eigentlich nur, denke ich mir so,

okay, ich habe keine Ahnung, wie genau es

passieren wird, aber irgendwie in der nächsten halben Stunde wird

mir schon irgendwas einfallen. Und dann probiere ich halt einfach rum

und dann hinterher denke ich so, okay, das war's, aber keine Ahnung.

Ich weiß gar nicht, ich habe mir jetzt gar nicht genau überlegt, was ich

da tue, sondern es passiert irgendwie.

Das passt mit dem Blogartikel, den du mir letztens geschickt hast,

wo du sagtest, wie lange sollte man eigentlich

über Probleme nachdenken? Und die Antwort war eigentlich

so, ja, eigentlich gar nicht.

Genau, würde ich auch inzwischen

sagen, eigentlich lieber, wenn man

nicht direkt weiterkommt, halt einfach was anderes machen.

Später nochmal drauf zurückkommen.

Duschen gehen, es fällt einem wie Schuppen von den Augen.

Aber das ist ja auch direkt eine gute Überleitung.

Ja.

Weil bei Packages ist ja auch oft das Problem,

dass wenn man entweder auf der

gebenden oder auf der nebenen Seite des Packages steht

und dann einen Bug hat,

beziehungsweise auch irgendwie so eine gewisse Maintenance machen

muss, zum Beispiel gibt es eine neue Dango-Version und man wird

inkompatibel, das passiert ja leider

immer wieder mal und das ist

tatsächlich auch eine Sache,

dass wenn man so ein Package in die Welt setzt,

ich nehme jetzt mal extra dieses Wort,

dass man halt da schon ein bisschen im Kopf

behalten sollte, wie gehe ich denn damit um

mit der Maintenorship, also wenn man sagt, ich mache das jetzt für mich

und mal zum Ausprobieren, das nutzt eh keiner.

Ich suche immer noch kurz den Übergang von der Dusche,

aber okay, du bist für ein Maintenorship, ja.

Nee, wegen Bugs und Problemen.

Ja, wie lange man nur dran nachdenken sollte.

Genau.

Und das ist tatsächlich auch eine Sache,

das merke ich halt auch oft,

dass ich halt vor allem in älteren Projekten, die ich habe,

dass ich da halt ein sehr cooles Package verwendet habe.

Würde ich heute nicht mehr machen,

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

Und dieses Package ist halt irgendwann mal hart abandoned worden.

Also, dass da wirklich die Leute einfach kein Interesse mehr daran haben.

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

hey, ich schreibe einfach sorry, ich weiß ich nicht,

ich bin jetzt irgendwie Gärtner und ich mache kein Programmieren mehr,

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

Obwohl die Leute halt immer noch aktiv sind.

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

Und das ist halt immer wieder sehr ärgerlich.

Und ich glaube, dass wenn man so ein Paket in die Welt setzt,

und man irgendwann merkt, okay, ich habe jetzt den Fokus verloren

und das nutzt aber vielleicht noch irgendwer.

Ich glaube, das Erste, was man machen kann,

ist halt, dass man irgendwo prominent eine Möglichkeit hat,

dass man den Leuten Feedback geben kann.

Also offensichtlich ist es einfach bei GitHub, die Issues.

Die kann man übrigens auch sehr schön über die,

zum Beispiel Setup Highlight oder Project Setup Tommel,

direkt verlinken in PyPy,

dass die Leute direkt,

über das Change-Log und so,

kann man alles perfekt verlinken,

dass die Leute gar nicht lange suchen müssen.

Und dass man dann auf jeden Fall Leuten,

die das halt nutzen,

die Möglichkeit gibt,

dass sie Feedback geben.

Also zum Beispiel,

ich habe die ersten zwei Issues bekommen,

tatsächlich mit Übersetzungen,

weil halt in dem Package halt ein paar Models,

die ich da bereitstelle,

waren halt auf Deutsch,

weil die meisten Projekte,

die wir nutzen,

sind halt auf Deutsch.

Und es ist halt nicht aufgefallen,

dass da der Übersetzungshelfer fehlt.

Und das war dann für die Leute halt echt super ärgerlich,

weil die halt das irgendwie nutzen wollten.

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

Wenn der gut translatet, dann kommt irgendein Unsinn raus.

Genau, und das hat mich dann total gefreut, es kam auch direkt ein Pull-Request hinterher, hey, hier so und so, und hab dann auch die Übersetzung nachgezogen und alles super, ne, also hätte ich sonst niemals rausgefunden, weil bis die irgendwie dann über die Webseite irgendwie mich anonym anschreiben oder mich über LinkedIn suchen oder keine Ahnung was, ist das ein riesen Overhead und so, einfach kennt halt jeder, ist schnell gemacht und das ist, glaube ich, so ein kleiner Convenience,

die man dann seinen Usern irgendwie

bereitstellen kann, weil es kostet ja auch nichts, es ist ja echt schnell

gemacht. Und wie gesagt, das andere

mit der Maintenorship, wenn man halt wirklich

sagt, okay, ich gebe das jetzt auf,

es gibt ja so

entweder so Projekte, so wie Jazzband oder sowas,

da gab es noch mit der DjangoCon einen schönen Vortrag dazu,

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

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

raus hier mit dem Kram, aber das nutzt noch Leute,

bitte kümmert euch drum.

Und auf der anderen Seite,

dass man natürlich auch dann notfalls auch andere Leute

einfach befördern kann und einfach

sagen kann, hier

das,

also ich habe da jetzt irgendwie Interesse und ich muss das reparieren

und sage, gut, ich habe selber keine Zeit, dann mach halt.

Ist immer noch besser, als wenn es gar keiner

macht.

Ja, ist ja gar nicht so einfach. Also gerade bei Leuten,

die halt for pleasure entwickeln,

da muss man sich halt auch überlegen,

will man nicht auch mal was Neues machen oder sowas?

Dann ist das schon klar, dass das schon schwierig ist.

Immer an den alten Sachen, die irgendwie so mitzuschleppen.

Aber das ist ja oft, also bei mir ist das

keine bewusste Entscheidung, sondern das ist ja so,

es ist halt einfach nur viel Zeugs inzwischen

und

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

Ja, also manchmal möchte man halt auch mal

in den Garten gehen oder sowas.

Nein, das hatte ich jetzt gar nicht gesagt.

Nein, nein, also das ist ja kein großer Wille.

Aber dass man halt irgendwie,

dass man dann vielleicht wenigstens noch ab und zu auf GitHub

guckt, wenn jetzt einer sagt, hey, geht nicht mehr, dass man dann

sagt, ja gut, dass man den Leuten vielleicht kommuniziert

einfach so, hey, sorry.

Dann würden wir nicht sagen, wir lesen wahrscheinlich noch

so Nachrichten oder so.

Aber es ist auch die Frage, wenn du irgendwie 5000 am Tag kriegst

oder so, das ist wahrscheinlich dann auch anstrengend.

Je nachdem, welche Größe du hast irgendwann.

Das kann auch sehr overhelming werden.

Also gerade, ich sag mal, das Leben von Leuten

ändert sich ja auch oft. Also so Situationen

oder sowas.

Wenn da irgendwie dann die Prioritäten sich privat

verschieben und die Leute dann nicht mehr von morgens bis abends

dann noch in ihrer Freizeit

partizipieren können, dann...

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

Es hat ja auch Carlton Gibson, glaube ich,

macht gefühlt jede zweite Jungle Corner einen hervorragenden Vortrag zu dem Thema.

Das ist natürlich

ein Problem, aber ich sage, es gibt halt

relativ einfache Möglichkeiten, die

zwingend natürlich nicht bei jedem zutreffen, wenn einer wirklich

sagt, hey, ich habe jetzt den Beruf gewechselt

oder ich bin weggezogen oder keine Ahnung was und

habe meinen GitHub-Account geschlossen, das war es jetzt

für mich. Okay, kann immer passieren, aber

ich sage eben, in den meisten Fällen

ist es wahrscheinlich oft, dass Leute noch irgendwie

latent am Ball bleiben und

da gibt es halt ganz einfache Wege,

das Problem zumindest für einen selbst irgendwie zu lösen.

Ja, ich sage mal so, es ist schon

schön, wenn man halt so ein paar Issues irgendwie

die größten nicht offen lässt, sondern zumindest

ein Team findet, das dann Lust hat, wenn man gerade

wirklich viele Leute hat, die dann was benutzen,

dass denen halt wenigstens mal deren Pull-Request-Merch

oder denen die Möglichkeit gibt, dass die selber

Sachen merchen können oder die Interesse dann haben.

Klar kann man auch einfach forken und dann irgendwie

ein neues Package machen und sowas, aber

es ist halt natürlich schon

schön, damit das alles irgendwie ein bisschen zentralisiert ist.

Aber die Jazzband hast du ja erwähnt,

das ist glaube ich eine ganz gute Möglichkeit, das zu tun, ja?

Ja, ja, da bin ich jetzt,

da hat sich halt im letzten Mal auch was getan, da bin ich jetzt

auch mal da beigetreten.

Und dann, weil ich habe

nämlich gesehen in dem Projekt, in dem ich momentan gerade

da rumschraube, da habe ich diverse

Geschichten, die in Jasmine drin sind, reingewendert.

Sozusagen,

damit ich die anpassen kann.

Und eigentlich kann ich das ja auch dann einfach

so machen vielleicht.

Cool.

Dann löst du quasi dein Problem

und hilfst aber noch ganz vielen.

Ja, gut, das vielleicht mache ich auch

demjenigen, der dann die nächste Release baut,

Kopfschmerzen. Das kann auch sein.

Aber ja, mal schauen.

Ist auf jeden Fall interessant.

Ist vielleicht auch eine kleine Verbesserung.

Ja, ja.

Tja, was haben wir denn?

Was gibt es denn noch

so für Dinge, die wir über

Packaging irgendwie

erzählen sollten?

Habt ihr irgendwie

irgendwelche Tools, die ihr

bevorzugt verwendet? Also Flit, okay, kanntet ihr jetzt

nicht. Habe ich auch nicht.

Werde ich dann demnächst mal ausprobieren. Mal gucken.

Das ist irgendwie voll gut.

Ja, Poetry

verwende ich meistens, aber

Ja, tatsächlich so zum normalen

lokalen Verwalten schon und zum Bauen.

Du verwendest pipenv, aber das ist nur

für die

Genau, nur für die Requirements.

Ja, genau.

Tatsächlich, das Package,

das schiebe ich noch

mehr oder weniger genauso hoch, wie das damals

2012 war, also so eine ganze fiese Set, also

das heißt fies, aber aufgeräumt ist sie aber eine

sehr angestaubte Setup-High.

Und ja, dann auch, ich baue da auch ein Wheel draus,

weil das für, also ich selbst bin ja tatsächlich ein Windows-Nutzer.

Das wird jetzt auch ein bisschen populärer.

Aber wieder beim Coden.

Aber tatsächlich ist es mit den Wheels sehr, sehr angenehm,

weil die Sachen sich einfach alle installieren lassen

und man da keinen Knatsch mehr hat.

PyCurl ist aktuell mein einziger Endgegner.

Wenn ich das installieren möchte.

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

Ich meine, gut, dass du das gesagt hast.

das werde ich dann in ihrem Nachgang mal anschauen, weil

ich hatte eh schon immer mal überlegt, ich würde da gerne

was machen, aber wie du schon auch gesagt hast, es gibt

so viele Wege, die nach oben führen und wenn ich jetzt gerade keinen

unbedingten Druck habe, was

zu ändern, dann ist mir dann auch so eine Sache,

die auf der To-Do-List dann gerne mal ein bisschen nach hinten rutscht.

Ja, ja, auch in diesem, auch in

der Episode mit Brad Cannon, der meinte halt so,

eines der Hauptprobleme, die sie so haben,

auch irgendwie, also der

Grund, warum das alles so zersplittert und kompliziert

ist, ist halt auch, dass

der Haupt

Weg, wie Entwickler das machen und

das erinnerte mich jetzt gerade daran, ist halt, dass

sie irgendwann mal sich damit beschäftigt haben

und dann haben sie ein Setup-Wi-Fi geschrieben und

das kopieren sie halt Projekt von Projekt

zu Projekt immer weiter. Und das Problem

ist halt sozusagen

aus Infrastruktursicht dann,

ja, Abwärtskompatibilität ist halt

super wichtig, weil

es sind halt oft viele Dinge

immer noch im Einsatz, die von irgendwann an oder

dazu mal kopiert worden sind. Das heißt, man

kann die Abwärtskompatibilität nicht mehr brechen, weil

ansonsten bricht ganz, ganz viel,

ganz, ganz viele Dinge und dessen

ja, Vorschlag

war auch eher SetupCFG

zu verwenden und dann halt auch mal

oder irgendein Projekt-Template oder so

oder eben ein Tool, was einem das halt

abnimmt, ja. Das klingt aber

auch alles schon wirklich, also ganz im ganzen

Packaging-Ding, ne, so gordischer Knoten.

Ja, das ist wirklich gemein, ja, ich meine, was will man

machen, wenn du, ja,

ein Großteil der Pakete da draußen verwenden halt uralte

Geschichten und du kannst es nicht mehr ändern, weil

wenn du es änderst, dann brichst du all die Pakete.

Wegschmeißen, neu machen, auf Features verzichten, vielleicht braucht man

die alle gar nicht.

Ich habe das Wesentliche

konzentriert.

Ja, aber genau, ich habe auch einmal so ein

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

Python-Package

Cookie-Cutter-Template von

Pied Denny. Genau.

Und das fand ich

auch ganz nett, aber... Der übrigens auch auf Twitch streamt.

Bitte? Der übrigens auch auf Twitch

streamt. Ja, ja, richtig, genau. Das habe ich mir auch schon

so ein bisschen

angeguckt. Genau, fand ich auch gut.

Ja, okay.

Was ich auch ganz interessant finde,

apropos Projektsetup,

der Code, der jetzt in meinem Package drin ist,

der ist natürlich auch logischerweise getestet.

Also am Anfang war nicht so viel getestet.

Logischerweise, natürlich, Ronny.

Inzwischen ist er getestet, zumindest Großteils.

Also die Sachen, die ich halt tatsächlich nutze,

die sind jetzt auch getestet.

Und am Anfang war es auch so,

dass diese Testfiles dann einfach mit in dem Package gebandelt wurden.

Also die Metatests quasi,

also die Sachen, die das testen, was ich nachher ausliefere,

mir ist dann nachher mal aufgefallen, die muss ich ja gar nicht mit ausliefern.

Weil das interessiert einfach keinen.

Vielleicht ist es ja doch, weil die

wissen wollen, ob ich vernünftig das abgedeckt habe.

Aber eigentlich liefere ich eine Datenmenge aus,