Ja, hallo, liebe Hörerinnen und Hörer. Willkommen beim Python-Podcast, Episode 51.
Wir hatten eine relativ lange Sommerpause.
Ja, ungeplant.
Ungeplant. War ein bisschen was dazwischengekommen.
Das haben uns auch schon viele Leute geschrieben.
Wir loben Besserung, ja. Liebe Grüße.
Genau. Danke für die Erinnerung, dass wir mal irgendwie wieder was machen sollen.
Wir wollen heute über Environment Management und Packaging sprechen.
Und wir haben die Annalena heute sogar. Hallo, Annalena.
Ja, hallo.
Hi, ihr beiden.
Magst du kurz was über dich erzählen vielleicht? Vielleicht fangen wir so an.
Ja, na klar. Genau, mein Name ist Annalena Popkes.
Ich arbeite als Machine Learning Engineer bei einem deutschen Unternehmen, das nennt sich Innovex.
Und bin da in verschiedenen Kundenprojekten unterwegs.
Je nachdem, was der Kunde möchte, mache ich verschiedene Dinge.
Manchmal auch reines Data Engineering.
Jetzt gerade bin ich bei Bubble.
Das ist ein Unternehmen, was Sprachen beibringt.
Kennt ihr vielleicht auch schon.
Habt ihr vielleicht selbst schon mal benutzt.
Und ich arbeite da im Speech Recognition Team.
Und helfe da dem Team dabei, ihre Software weiterzuentwickeln, produktiv zu nehmen und was da alles so dazukommt.
Oh ja, sehr cool.
Klingt echt total interessant.
Ja, finde ich gut.
Ist super spannend.
Ja, ist auch ein ganz interessantes Unternehmen, finde ich, wenn man dann mal etwas mitarbeitet, was auch wirklich beim User Verwendung findet.
Das ist sehr unterschiedlich, was man da für Kundenprojekte hat, was passiert mit dem Code, den man da so schreibt.
Und das finde ich total...
Rewarding, also, dass es einem viel zurückgibt, an etwas mitzuarbeiten, was man auch vielleicht selbst schon mal benutzt hat.
Ja, stimmt, das ist gut.
Und dabei bist du auch über Environment-Management-Packaging-Zeugs gestoßen oder gestolpert, oder ist das ein Hobby von dir?
Nee, das war bei einem vorherigen Kundenprojekt.
Da wurde ich gefragt, also Packaging ist ja sehr präsent, wenn man viel mit Python macht und dementsprechend ist mir das schon vorher begegnet.
Aber ich habe mich da noch nie so wirklich reingearbeitet gehabt.
Aber in einem vorherigen Kundenprojekt.
Wurde ich dann mal gefragt, welches Packaging Tool sollen wir denn benutzen?
Es gibt ja so viele.
Und dann hatte ich angefangen, mich mal ein bisschen reinzulesen und dachte, boah, ich finde wirklich viele Blogartikel zu den einzelnen Tools.
Aber ich finde nicht so wirklich einen Artikel, der die verschiedenen Tools zusammenfasst, mal kurz erklärt, was sie können, wozu sie geeignet sind und das Ganze vernünftig kategorisiert.
Vor allem ohne diese persönliche Präferenz reinzubringen, die man ganz viel findet, die ich auch ganz viel...
Ja.
Unter Kollegen halt bemerkt habe, dass manche sagen, ja, Poetry auf keinen Fall will ich nicht benutzen.
Die haben da mal so ein Release rausgebracht und der hat total viel kaputt gemacht.
Und nee, das mache ich jetzt kategorisch nicht mehr.
Ja, das sagt Jürgen auch.
Ich benutze es noch.
Wir hauen uns da im Karten.
Und dementsprechend dachte ich dann, okay, jetzt wird es mal Zeit.
Das ist eine gute Möglichkeit, mich da mal tiefer reinzuarbeiten, da auch einen Talk zuzumachen und einen Blog zu schreiben, einen Blogpost zu schreiben.
Und das habe ich dann gemacht.
Und das hat erstaunlich viel Anklang gefunden.
Wobei, wenn man jetzt so darüber nachdenkt.
Wahrscheinlich gar nicht so erstaunlich, weil das ein Problem ist, was so viele Leute betrifft.
Ja.
Und das Ganze...
Also ich würde ausdrücken, das ist so das Hauptproblem, wenn ich halt auch einen Neuling oder sowas versuche, Python beizubringen oder irgendwie irgendwas zu zeigen.
Das ist immer eine große Hürde, bis erstmal alles läuft und bis man irgendwelche Environments erstellen kann und so weiter.
Und jetzt reden wir ja noch nicht über Packaging, aber einfach nur dieses Environment-Setup in Python ist so ein bisschen nervig.
Ja.
Und nicht nur ein bisschen, sondern sogar ziemlich nervig.
Und ja, ich bin da auch tatsächlich da auf deine Meinung sehr gespannt hinterher.
Auf deine Meinung.
Persönliche Präferenz, was du sagen würdest, was so am besten funktioniert.
Aber ich finde das cool, dass wir diese ganzen Tools haben und vielleicht können wir über die einzelnen Tools noch irgendwie reden.
Normalerweise machen wir es ja immer so, dass wir einen großen News-Teil vorne haben, aber da wir halt seit Mai, glaube ich, keine Folge mehr hatten, da hat sich da so einiges eingesammelt.
Ich würde sagen, das ist fast eine eigene Folge.
Das müssen wir, glaube ich, an einer anderen Stelle nochmal so ein bisschen nachholen.
Aber gut, so ein bisschen was können wir ja machen.
Ach, doch so ein bisschen was.
Ja.
Na gut.
Worüber willst du erzählen?
Ich weiß es nicht.
Einfach nur das, was mich in letzter Zeit so ein bisschen beschäftigt.
Oder wo ich dachte...
Okay, kann ich jetzt was zu sagen, weil es mich gerade betroffen hat?
Zum Beispiel, es gibt irgendwie ja...
Also, seit letztem Mal Pydentic Version 2 ist raus.
Ah, ja, natürlich.
Und jetzt inzwischen sogar 2.4.
Wir haben ja auch die ganzen Europe-Python-News noch nicht gemacht.
Ja, richtig.
Eine ganze Menge.
Und genau, da habe ich jetzt auch letztens ein Projekt umgestellt.
Ich wollte es eigentlich nur updaten und dann hat das halt irgendwie nicht so gut funktioniert.
An Pydentic 2 ist jetzt, dass dieses Rust-Core, das halt vorher Pydentic-Core war, also als Extra-Library jetzt mit drin ist, direkt in...
Pydentic selbst, ja.
Ja, genau.
Das heißt jetzt auch schnell.
Das ist jetzt...
Das, was vorher langsam war, das ist das Hauptproblem, was Pydentic halt so hatte bei der Validierung, geht jetzt einigermaßen flott.
Ja, sollte jetzt deutlich schneller gehen.
Ja, ja, genau.
Ja, das Problem ist halt, dass Objekte erzeugen halt, wenn man das rein in Python macht, sehr langsam ist.
Wenn man jetzt irgendwie lange Listen von 10.000 irgendwie Einträgen in einem JSON-Ding hat, dann dauert das halt irgendwie, wenn man das in Pure Python macht, das alles zu validieren.
Und in Rust geht das halt deutlich schneller.
Und, ähm, ja, aber, äh, genau, also, ähm, ach so, das hatten wir auch noch nicht erwähnt, äh, ähm, es gibt jetzt eine Firma hinter Pydentic, äh, und die hat auch irgendwie, glaube ich, von Sequoia oder so, ordentlich Venture-Craft-Value bekommen.
Mhm.
Und die Entwicklung...
Das habt ihr, glaube ich, erwähnt in der letzten Episode.
Hatten wir schon erwähnt, ach so, gut.
Kann sein.
Habt ihr schon erwähnt, ja.
Ja.
Äh, okay, genau, aber die Entwicklung geht da jetzt auch deutlich schneller und, ähm, genau, das Update, das ich dann jetzt probiert habe, war aber nicht so reibungslos.
Das war halt echt, das war richtig übel.
Das hat deutlich länger gedauert, als ich so gedacht hätte.
Ich meine, das ist halt auch so ein Ding, äh, das kann dann passieren, wenn man Dinge ändert, ne, da halt halt irgendwie, früher war es halt so, dass, wenn man, äh, bei einer, ähm, äh, bei so einem Feld gesagt hat, typing any, dann war das default-mäßig none.
Mhm.
Und, ähm, das ist es jetzt nicht mehr.
Jetzt ist es halt, kriegt man einen Fehler und das sagt halt irgendwie, du hast da einen, äh, hast da einen Wert nicht gesetzt.
Und dann drunter kommen aber die anderen Variablen und dann hatte ich das irgendwie falsch einsortiert und bin dann irgendwie falsch abgebucht.
Und dann musste ich halt irgendwie, weil das, es hat sich auch noch ganz viel anderes Zeug geändert.
Ich dachte so, welche Änderung hat das jetzt verursacht, dass ich da jetzt immer einen Fehler kriege?
Und ich habe wirklich lange suchen müssen, bis ich das rausgekriegt habe, dass das der Grund war.
Manche Sachen sind gemein, die beißen einen.
Äh, ja, das war schon, dachte ich so, mhm, ja.
Aber im Grunde ist das natürlich eine tolle Sache, dass das jetzt irgendwie alles irgendwie auch schnell funktioniert und so.
Ja.
Aber ich werde wahrscheinlich noch ein bisschen, bisschen brauchen, bis ich alle Sachen, die ich, wo ich Freidentik verwende, da umgezogen habe.
Benutzt du das auch in Django?
Ähm, ja, ich benutze es in Django-Projekten teilweise auch, wenn halt vor allen Dingen Daten von außen irgendwie kommen, um die halt zu validieren, verwende ich das halt.
Also wenn es halt nicht über quasi Django REST-Framework geht.
Genau, ich wollte gerade sagen, du hast keinen Django REST-Framework.
Doch, also für, für, für, für so REST-Apps nehme ich normalerweise Django REST-Framework, aber manchmal kommen Daten ja auch von woanders und dann, dann nehme ich schon ein paar Identik.
Aber da gab es ja auch ein paar News zu, ne? Ich glaube, REST-Framework wird irgendwann duplicated und nach Django reinwandern, irgendwie jetzt mit 5 sogar schon, dann.
Ja, das weiß ich nicht.
Das weiß ich noch nicht. Also die, die Kerngeschichten wandern in den, wandern in Django selber rein.
Ähm, ja, also quasi das Encoding-Geschichten, also es gibt, ja, größere Teile, die in Django jetzt selber sind und dann könnte man halt sowas wie Django REST-Framework relativ leicht in Django selber reinpacken.
Aber Django REST-Framework selber, glaube ich, kommt nicht, also mit allem, was so dranhängt, auch nicht rein, weil das ist halt einfach so riesig.
Ja, vielleicht, aber natürlich keine Sache, ne?
Dann kann ich dann gar nicht mehr, wenn man das einfach so reinpackt.
Dann ist es auch nicht mehr großartig, genau. Das ist halt, ja.
Insbesondere, wenn man dann diese Pidentic-Validation macht oder sowas, ja.
Ja, ja. Ja, also das ist auch noch interessant. Also es gibt ja dieses Django Ninja oder so.
Ja, okay, das ist komisch.
Ja?
Ja, also ich finde schon.
Okay. Ja, das habe ich auch noch nicht verwendet, also müsste ich mal vielleicht.
Ja, ansonsten, äh, was habe ich denn noch so? Ach ja, die LLM-Geschichte, das war ja die vorletzte Episode.
Ja, ja.
Da haben wir uns also quasi gerade mit beschäftigt.
Die eskaliert auch immer noch so munter von sich.
Und wird immer, äh, äh, da gibt es auch jede Menge Neuigkeiten. Kann man auch nicht alles abdecken, ist einfach so viel, was da passiert.
Aber, äh, ne, ne Haupt-, ne, ne, äh, wichtige neuere, äh, neuere Geschichte, die da passiert, ist halt irgendwie, und das will ich mir unbedingt angucken, hab's noch nicht geschafft.
Aber, was man jetzt machen kann, ist halt, äh, tatsächlich, äh, irgendwie mit, mit Lama 2, was halt jetzt so richtig offiziell irgendwie, ähm, dafür, äh, gedacht ist, dass man damit Dinge machen kann.
Das kann man halt super feintunen, gerade die kleineren Modelle kann man super feintunen auf irgendwelche Problematiken.
Und dann braucht man halt nur ein paar tausend Beispiele für irgendwas und kann da halt dann, ohne dass man die Daten zu OpenAI schickt oder sonst irgendwo hin, äh, irgendwie Dinge damit machen.
Mit guten Ergebnissen.
Mit sehr guten Ergebnissen. Es gibt ganz viele Leute, die davon total schwärmen und die sagen, das ist total super.
Irgendwie, wenn du da in der Richtung irgendwas machen kannst, lass alles stehen und liegen und mach das, weil das ist halt so großartig.
Ja.
Ja, okay.
Daher, ähm, ja.
Hab ich mir auch schon gedacht und gedacht, nee, mach ich nicht, aber.
Ja.
Ich würd gern.
Naja.
Ja.
Weißt du, was ich rausgekommen bin?
Von dem, wofür man LLMs noch wunderbar benutzen kann, wo ich sehr überrascht war?
Nee.
Sag mal.
Musiktipps.
Musiktipps?
Ja.
Okay.
Das fand ich hervorragend.
Also, also, fast mit das Beste, was du hast.
Du hörst irgendwas Schönes und gibst dann halt so das, was du magst.
Aber als Kontext, wenn du sagst, hey, ich hör das und das gerne, hast du ein paar gute Tipps, was rauskommt.
Also, ich fand die Tipps hervorragend.
Ich hab so ein paar Sachen gefunden, die ich noch nicht kannte und so.
Cool.
Hab ich noch nicht verwendet für, aber klingt, äh, klingt gut.
Ja, muss ich mal probieren.
Ich glaube, dazu gab es tatsächlich sogar einen Talk genau mit der Topic bei Europython.
Ach, echt?
LLMs for Music Recommendation.
Ja.
Ach, witzig.
Toll.
Ich hab, ich hab's nicht gesehen.
Ich dachte gerade, du hättest den gehört.
Nein, hab ich tatsächlich nicht gesehen.
Sonst hätte ich den auch jetzt empfohlen.
Aber den hab ich tatsächlich verpasst.
Die sind jetzt alle auf YouTube seit, seit einer Woche, glaube ich.
Ah, gut.
Okay, also auch noch, das musst du auf jeden Fall auch in die Show-Notes, ne?
Dann können wir nochmal die Europython-Talks verlinken.
Ja.
Genau.
Ansonsten, ja, äh, Postkarten.
Das 16 ist raus.
Ist jetzt zwar nicht so wirklich was mit Python zu tun, aber, äh, vielleicht, äh, ja, die
meisten Leute, oder, dürften ja auch irgendwie den Datenbank verwenden und viele verwenden
wahrscheinlich Postgres und da hab ich jetzt auch meine, meine ganzen Geschichten geupdatet
und, äh, das ging auch problemlos.
Also von, von 15 nach 16, wenn der PG-Upgrade einfach drüberlaufen lässt, das hat einfach
immer so funktioniert, auch mit 14.
Also es war ein sehr problemloses Update.
Mhm.
Für mich.
Und, ähm, ja.
Hat auch eine Menge nette Sachen drin.
Boah.
Also ansonsten, weiß nicht, habt, habt ihr vielleicht noch irgendwas, was euch einfällt,
was man mal erwähnen könnte, was in letzter Zeit Interessantes passiert ist?
Ich bekomme vor allem durch die Arbeit viel mit über die Large-Language-Modelle, aber
du hast ja auch gerade so gesagt, das sprengt absolut den Rahmen.
Wir haben da auch einen Channel zu bei der Arbeit, ähm, und da sind täglich mehrere
Posts, also da kommt man überhaupt nicht hinterher, weder sich das alles anzulesen noch, also
ich bekomme die großen Releases mit von den Modellen, aber darüber hinaus finde ich
schon fast, könnte ich fast den halben Tag damit verbringen, Artikel zu lesen zu den
verschiedenen Dingen, die da passieren.
Ja, ja.
Das ist halt mal so.
Ja, ja, ist aber die Frage, was dann die richtige Strategie ist, ob man irgendwie dann mitmacht
oder sagt, naja gut, jetzt warten wir erstmal ein paar Monate, bis sich das alles so ein
bisschen gesettelt hat und dann die Sachen, die halt dann als sich als, äh, das wird
bleiben oder es nicht so, äh, es nicht nur Hype irgendwie erwiesen haben, da, sich das
dann nochmal anzugucken.
Ich weiß es nicht.
Ah.
Schwierig.
Ja.
Äh, ja gut, aber ansonsten.
Ja, ich würde, meine News sind alle so, gerade nicht so technisch, natürlich, deswegen
skippen wir die für heute einfach mal.
Okay.
Jut, jut, jut.
Ja, dann können wir ja eigentlich direkt zum Thema übergehen, nahtlos.
Wollen wir mit Environment anfangen oder mit Packaging?
Ich würde sagen Environment, oder?
Ja.
Hätte ich auch gesagt, ja.
Okay.
Ähm, wollt ihr auch über das Python Version Management reden?
Das hatte ich auch als Kategorie noch mit aufgenommen.
Ja, also Finte gehört auch dazu und das überschneidet sich.
Das überschneidet sich ja teilweise auch, weil auch PyEnv ja Virtual Environments macht
und so, wenn man, wenn man will.
Ja.
PyEnv ist vielleicht ein guter Anstieg, also weil ich würde tatsächlich mit PyEnv wahrscheinlich
anfangen auf so einem System, um Python selber zu installieren.
Ich würde das halt nicht irgendwie über die Website machen, sondern tatsächlich irgendwie
versuchen, PyEnv irgendwie zu klonen und dann in den Pfad zu packen und dann halt verschiedene
PyThons installieren zu können.
Das funktioniert ja leider nicht so gut auf, auf Windows-Maschinen, sondern halt nur auf
POSIX.
Es gibt aber so ein Fork.
Der das auch für Windows macht, der in den letzten Jahren so ein bisschen besser geworden
ist und es ist jetzt einigermaßen benutzbar, aber es hat halt nicht so schöne Sachen auch
drin wie Minikonda oder sowas, was ja bei der POSIX ganz gut funktioniert.
Ich weiß nicht, ob ihr.
Bin auch ganz froh, dass ich meistens mit einer Linux-Maschine arbeiten kann und nicht
unbedingt auf Windows zurückgreifen muss, da ist es häufig ein bisschen leichter, alles
aufzusetzen.
Ja, also es ist in den letzten Jahren ein bisschen besser geworden.
Ich muss das halt recht häufig machen, aber es geht mittlerweile.
Also ja, ich weiß nicht.
Vielleicht.
Das geht ja auch an mit PyEnv.
Also ich würde tatsächlich PyEnv installieren und dann mit PyEnv die Python-Version installieren,
die das Projekt gerade haben will.
Genau.
Ich weiß auch gar nicht, ob viele Einsteiger bei eurem Podcast dabei sind.
Also vielleicht können wir auch immer noch mal sagen, was die Tools überhaupt machen.
Ja.
So zur Vollständigkeit.
Sonst sind sie alle wieder direkt aufgeschaltet.
Oh ja.
Das Feedback habe ich schon ein paar Mal bekommen.
Das war aber ganz schön schwierig.
Ja, genau.
Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt
habe.
Das war ganz schön schwierig, ja.
Ja, genau.
Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt
habe.
Das war ganz schön schwierig, ja.
Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt
habe.
Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt
habe, ob es Kategorien gibt, weil bei Python gibt es eben unheimlich viele Tools, die alle
verschiedene Dinge können und manche können mehrere Sachen und eine bestimmte Kategorie
ist eben Python Version Management, sprich, dass man ein Tool hat, das einem erlaubt,
verschiedene Python-Versionen herunterzuladen oder zu installieren, ohne dass man das manuell
machen muss und dann, dass man eben auch leicht zwischen den Versionen wechseln kann.
Und PyEnv ist so das bekannteste Tool, glaube ich, dafür und auch eines der wenigen Tools,
das es wirklich macht, viele, die das, also zum Beispiel Rye ist so ein Multi-Purpose-Tool,
was viele verschiedene Dinge kann, aber sonst die meisten können gut mit PyEnv interagieren,
also man kann beides zusammen nutzen, aber PyEnv ist, glaube ich, so das Tool und auch
ziemlich leicht zu benutzen, wenn man es erst mal installiert hat, gibt es einfache Befehle,
womit man dann einfach spezifizieren kann.
Ich möchte gerne Version 3.10.4 und dann installiert es die Version und man kann leicht
zwischen der und anderen Versionen hin und her wechseln.
Ja, also ich brauche es auch genau, also lokal, wenn ich irgendwie auf einer Entwicklungsmaschine
unterwegs bin, da ist das halt etwas, was ich auch ständig brauche, weil viele, also
ich arbeite ja auch für unterschiedliche Kunden mit unterschiedlichen Python-Versionen
teilweise und wenn man halt ein Virtual Env mit einer bestimmten Python-Version haben
möchte, dann ist halt PyEnv genau das, was man dann an der Stelle haben möchte.
Ich glaube, es gibt noch ASDF zum Beispiel.
Das macht das dann halt nicht nur für Python, sondern halt auch noch für quasi Node.js und
für Ruby oder sowas.
Keine Ahnung, habe ich dann nicht probiert, weil den Anwendungsfall habe ich so selten,
dass ich das nicht brauche.
Und genau, es macht halt auch so Dinge wie, also PyEnv macht auch noch so Sachen wie, man
kann halt Minikonda, also es gibt ja auch so ganz unterschiedliche Python-Ökosysteme,
also je nachdem, also wenn man im Data-Science-Umfeld unterwegs ist, da ist halt
eher so Conda, das Tool, was man benutzt, um halt Applikigkeiten zu installieren und
vielleicht will man halt dann eher so die Minikonda-Python-Version haben, was wieder
was anderes ist als diese komplette Anaconda-Distribution, das habe ich auch schon ganz oft gesehen, dass
Leute mit der anfangen und das dann halt für Sachen verwenden, wo ich denken würde, oh
nein, da brauchst du eigentlich Minikonda und irgendwie ein Virtual Env oder so, kannst
das komplette Ding, ist halt, ja.
Das ist oft halt so ein Einstiegspunkt, weil das halt oft in der Data-Science-Welt irgendwie
sehr empfohlen wird als Entry-Point.
Ja, ja.
Kann man mit PyEnv auch die ganzen Dialekte installieren?
Also sowas wie A-Python oder H-Python oder sowas?
Das weiß ich nicht, also PyPy geht, ich glaube, Logel geht, aber…
Habe ich tatsächlich auch noch nie ausprobiert.
Keine Ahnung.
Ich habe auch gerade gedacht, dass so über Conda, Minikonda, Anaconda könnt ihr wahrscheinlich
auch sogar eine ganze Semper-Art-Folge machen.
Ja, wahrscheinlich, oh Gott, du musst nicht zu tief da abschweifen, weil, ja.
Genau, ja, Conda ist ja wirklich so ein ganz eigenes Ökosystem, ein bisschen, wo man dann
doch mal, das lohnt sich schon, finde ich, tiefer einzusteigen, damit man zumindest mal
einmal versteht, was der Unterschied zwischen Conda, Anaconda, Minikonda und so weiter ist.
Aber es ist schon wirklich ein riesengroßes Themengebiet.
Vielleicht sagen wir das nochmal kurz, wenn wir schon jetzt bei Conda sind, dann bitte.
Vielleicht haben wir das einmal so kurz so als Elevator.
Ja, also aus meiner Sicht, der Hauptunterschied ist, dass beim Virtual Env, bei dem normalen
Virtual Env in Python, da ist der Interpreter halt nicht mit dabei, sondern man verwendet
halt alle Virtual Envs.
Wir verwenden den gleichen Interpreter, die halt mit dem gleichen Interpreter erzeugt worden
sind.
Vielleicht nochmal ganz, ganz anstrengend, also ein Virtual Env ist tatsächlich eine
virtuelle, erzeugte Umgebung für das Python, für dein eigenes Projekt.
Ja, also es ist so ein bisschen Magie, dass man die Pfade umbiegt, aber das hat den Effekt,
dass man alles, was man da drin, also wenn man jetzt irgendwas mit PIP-Install irgendwas,
eine Abhängigkeit installiert, dass die halt nur in dem Environment tatsächlich installiert
ist und nicht in allen, die man sonst irgendwie, also sonst halt nicht, sodass ich halt, wenn
man jetzt mehrere Projekte hat, dann kommen die sich ja sonst in die Quere, wenn man halt
in dem einen irgendwie, weiß ich nicht, Django 3 hat und im anderen Django 4, dann, die werden
sozusagen im gleichen, ja, auf dem gleichen Isolationslevel, dann würde man ja quasi
die Abhängigkeiten vom einen kaputt machen, wenn man im anderen was ändert und um das
voneinander zu isolieren, nimmt man halt Virtual Envs, üblicherweise.
Und ja, das ist halt sozusagen, Virtual Env ist so der, die leichtgewichtigste Art von
Isolation, weil der Interpreter ist, wenn man jetzt zwei unterschiedliche Projekte mit
zwei unterschiedlichen Virtual Envs hat, ist man halt noch gleich, aber die Pakete, die
installiert sind, sind halt gleich.
Genau, das ist ja auch ein Bild, ne, Python-M, Venv und dann Sachen.
Genau, bei Conda ist das anders, da ist der Interpreter tatsächlich mit dabei, das heißt,
auch die Interpreter sind voneinander getrennt und man kann mit Conda nicht nur Python-Pakete
installieren oder Python-Reels, sondern man kann halt auch andere Geschichten installieren,
das heißt, man kann zum Beispiel, das ist halt, deswegen ist das auch bei Data Science
immer so ein, so ein, so ein, aber das braucht man halt einfach häufig, häufig hat man
halt nicht so einen direkten Zugang zu den Maschinen, auf denen man irgendwie Dinge macht
und dann kann es schon mal sein, dass man dann eine alte LibC hat oder sonst irgendwas
und, oder alte Bibliotheken, die man nicht verwenden möchte und man kommt halt, man
hat ja gar nicht die Berechtigung, das sozusagen auf Systemlevel zu ändern und dann kann man
das mit Conda aber meistens schon irgendwie hinkriegen, dass man das halt dann, dass man
dann halt eine eigene Grundlagenbibliothek irgendwie mit installiert und die dann verwendet,
wird, statt dem, was auf dem System drauf ist, das geht mit Conda, das geht mit PIP nicht
und daher ist das halt etwas, was man halt, wenn man diese Probleme hat, dann, also wenn
man Webentwicklung macht, hat man diese Probleme normalerweise nicht, aber bei Data Science
kann das durchaus schon mal vorkommen und dann ist Conda da einfach das Ding, womit
man Sachen hinkriegt, die dann mit PIP nicht gehen.
Ja, da sind wir schon direkt drin, also es gibt ja PIP, was macht PIP?
Pakete von API installieren?
Ja, genau, vom Cheese-Shop und ja.
Und Conda installiert jetzt auch irgendwie externe Binaries noch und die gar nicht Python
sind und so und da gibt es noch ein anderes Tool für, das man häufiger nutzt, oder?
Noch eine Isolationsschicht weiter, oder noch weiter isoliert, also ein Tool, also ich würde
sagen, das nächste Tool in der Reihe wäre halt Docker.
Oder PIPX.
PIPX macht das gleich wie PIP, nur das ist halt für das, was du installierst, ein eigenes
Virtual Env erzeugt direkt.
Ja, oder es macht aber auch externe Sachen, also Sachen, die sich auf PIP einlegen und
da überziehen kannst.
Ja, okay, gut, das wusste ich gar nicht.
Ich habe gerade noch überlegt, vielleicht noch einmal zum Anaconda und Miniconda, die
Namen sagen das ja schon so ein bisschen, dass Anaconda wirklich riesig ist, das nimmt
auch unheimlich viel Speicherplatz ein, weil super viele Python-Packages, wenn man Anaconda
installiert, kommt das mit Python, dann ist Conda dabei, was ja der Package-Manager ist
von dieser Conda-Welt und aber auch super viele Packages, die man gar nicht unbedingt
braucht und dementsprechend, wenn man...
jetzt nichts dagegen hat, die Packages, die man braucht wirklich selbst zu installieren
und auch nicht unbedingt so viel freien Speicher hat, dann ist Miniconda eigentlich immer eine
gute Variante, was mit Python kommt, schon mit einer Version und eben mit Conda, mit
dem Package-Manager, sodass man die Pakete dann installieren kann, die aber von dem Conda-Index
kommen, dann nicht von PyPI.
Ja, ja, also ich denke, wenn man jetzt halt noch härter isolieren will als mit Conda,
dann wäre halt Docker das Ding, was man auch verwenden kann, was halt viele benutzen,
ja.
Ja, das ist halt langsam, aber ich finde Conda so ein bisschen intrusiv, weil Conda relativ
hart immer den Pfad direkt angreift, zumindest auf ein System und dann, ja, muss man immer
so ein bisschen aufpassen.
Ich glaube, also...
Ja, muss man bei all diesen Dingen...
Ja, generell, der Pfad ist immer so das, wofür viele Anfänger halt drüber stolpern,
wenn halt irgendwie im Pfad Dinge in der falschen Reihenfolge gesetzt sind und dann halt nicht
das Python läuft, was wir eigentlich denken, was laufen sollte und sowas, das ist so ein
bisschen hampelig.
Ja, ich habe auch mit Conda also anfangs immer angefangen, weil ich es praktisch fand, weil
so viel schon damit kam, aber mit der Zeit habe ich auch dazu gewechselt, die Python-Version
selbst zu installieren und nicht mehr auf Conda zurückzugreifen, auch weil ich das teilweise
verwirrend fand, dann manche Packages kann man gut mit Conda installieren, andere wieder
nicht.
Und dann fand ich es tatsächlich leichter, langfristig einfach die Dinge mit pip zu machen.
Aber ich weiß, dass viele Conda, vor allem wenn sie jetzt nicht aus dem Computer-Science-Bereich
kommen, doch recht hilfreich finden.
Mhm.
Ja.
Und ich weiß, dass die Leute, die mit pip auch die richtigen Build-Tools halt irgendwie
noch installiert haben als Dependencies und je nachdem, was für Dependencies dabei sind,
damit das gebaut werden kann, brauchen halt, weiß ich nicht, von C-Libraries über Haskell
oder sowas und das halt manchmal so ein bisschen anstrengend sein kann, wenn man nicht weiß,
was da passiert.
Ja, das hat alles so seine Tücken.
Ja, es ist leider kompliziert.
Ich weiß auch nicht, ich glaube nicht, dass man da, ich würde sagen, immer wenn jemand
fragt, ja, was soll ich denn nehmen, dann muss man eigentlich immer antworten, ja, hängt
davon ab, was man macht.
Und dann kann ich, ja, und das ist natürlich so ein bisschen eine doofe Situation, weil
muss man lange erklären und so.
Ja.
Ja, häufig finde ich es auch hilfreich, also ich arbeite ja immer an verschiedenen Kundenprojekten,
dementsprechend auch in verschiedenen Teams, dass die Teams sich ja häufig auch auf eine
Lösung einigen, sodass sie sich dann gegenseitig helfen können, dass dann nicht jeder sein
eigenes Setup hat, sondern dass sie sich auch vielleicht auf einen Editor einigen, den dann
alle ähnlich aufsetzen können, das ist mir schon häufiger begegnet.
Also da würde ich sagen, da gibt es immer große Widerstände, wenn man sich auf einen
Editor einigen kann.
Also es ist ganz gut, wenn die Sachen editoragnostisch funktionieren, also.
Ja, das stimmt, aber manchmal kann es auch ganz hilfreich sein, also ich finde, es kommt,
also es kommt wirklich sehr auf die Kundenprojekte auf.
Ja, solange alle Leute das so machen, wie ich das so richtig halte, ist das natürlich
so.
Ja.
Ja, ja.
Genau.
Wo waren wir denn überhaupt?
Genau.
Wir haben Python installiert und wollen jetzt halt ein Environment haben und dann gibt es
halt verschiedene Sachen, wie man das macht und wir haben jetzt gerade.
Also was ich gerne noch zu Python sagen würde, also ich benutze das halt für Entwicklungsmaschinen,
ne.
Da habe ich halt die Python Version, produktiv mache ich das eigentlich nicht, also nicht,
wenn ich es unter Kontrolle habe, wenn andere Leute das machen, die machen manchmal auch
andere Sachen, ich habe auch schon mal Python verwendet, um halt dann auf Produktivmaschinen
Maschinen eine Python-Version zu installieren
oder so, aber das mache ich jetzt eigentlich
nicht mehr, sondern ich installiere da hart,
ich kompiliere Python. Also, das ist auch so was.
Hätte ich nicht gedacht. Also, wenn mir jemand früher
gesagt hätte, also, in
zehn Jahren, weißt du, wie du da Python installieren wirst?
Du wirst es runterladen und auf der Maschine
kompilieren. Ich dachte so, nee, das
kann nicht sein. Doch, ist aber so.
Also, das ist tatsächlich die von mir momentan
präferierte Art, Python
auf ein Produktivsystem zu installieren, ist halt
selber zu kompilieren.
Postcode und bauen, okay.
Und auch nicht Python.
Ich habe Python auch selten in Kundenprojekten
benutzt, aber wenn man es mal ausprobieren
möchte, finde ich das auch ganz
nett, sich einfach mal die neueste Python-Version
runterzuladen damit. Dann kann man das
Tool mal ausprobieren und dann mal gucken, was
die neue Python-Version so
besonders macht oder mitbringt.
Beta-Version oder Release-Kandidates oder so, das ist immer
sehr nett dafür. Genau.
Ich überlege gerade, ob ich das cool finde, dass ich das selber
kompiliere im Produktivsystem.
Warum nicht Python für ein Produktivsystem?
Naja, deswegen, weil ich,
der Grund, warum ich damit dann aufgehört habe,
ist, dass ich dann irgendwie
nach längerer Zeit gemerkt habe, dass manche Projekte
halt eine alte Python-Version
verwendet haben,
wo ich das gar nicht mehr gedacht hätte, dass sie das tun.
Und das aber alles weiter funktioniert hat.
Und ich das aber gar nicht wollte.
Und dann habe ich gesagt,
ah, ist mir doch lieber, dass halt,
weil ich hätte sowieso gerne
immer die gleichen Python-Versionen für alle.
Aber den Fall, dass ich das unterscheiden will,
den habe ich gar nicht. Aber es kann ja mal sein,
dass du irgendwie so eine harte obere Schranke hast,
weil irgendein Projekt auf eine völlig veraltete
Library dependet, die halt schade ist, aber die halt
da irgendwie jetzt drin hängt. Und jetzt musst du halt
eine alte Version nehmen. Und dann...
Ja, passiert bei meinen Sachen nie.
Okay, ja, okay. Also ich habe so ein paar
Kunden, geht das so? Ja, ja, klar.
Ja, also der Vorteil von PyInf ist halt,
ich kann halt einfach auch die Version einfach dann installieren
und wenn in meiner Production Pipeline
PyInf halt drin ist, dann ist das halt ein leichtes
mal eben da auch mehrere Projekte
mit unterschiedlichen Python-Versionen auf einem Produktivsystem
laufen zu haben. Was halt, wenn ich das alles selber
kompilieren muss, wieder Hassel ist,
muss ich das alles selber konfigurieren. Das ist ja genau das,
warum ich ja solche Tools mit möchte.
Ja, siehste? Kommt drauf an.
Ja, leider.
Tja, ja.
Ja, also...
Da wären wir bei der Hoffnung, dass es irgendwann das eine
Tool gibt, was alles macht. Ja.
Sodass man dann nicht mehr diskutieren muss.
Da gibt es ja gerade tolle Versuche drin, das zu lösen
irgendwie, ne? Also man hört immer
Rust an der Stelle und ich würde auch sagen, dass tatsächlich
vielleicht gar nicht so eine doofe Idee ist.
Ich hätte das gerne, dass Python selber das so irgendwie anbietet.
Fände ich irgendwie cool, weil diese ganzen Tools,
die es von außen gibt, die sind alle so...
Also du hast eben Rye erwähnt, das ist das
Tool von Armin Runacher, was auch in Rust geschrieben ist,
der jetzt für Rust macht, dass so seine Opinion
ist, wie man so Projekte ein...
neu baut. Ehrlicherweise,
also ich bin da so ein bisschen anderer Meinung,
wie man das richtig machen würde. Also ich mache es anders,
mein Taste ist anders. Aber das ist eigentlich
ja so was, was es halt...
Ja, was man halt will.
Du hast vielleicht noch den großen Überblick von Tools,
die man dafür verwenden kann.
Ja, genau. Also
bei Environment Management vielleicht nochmal wieder
als Einführung, falls Leute dabei sind, die
da noch nicht sich so
gut mit auskennen. Also wenn man beispielsweise an
mehreren Projekten gleichzeitig arbeitet und
dann kann das immer mal wieder
vorkommen, dass Projekte das gleiche Package brauchen,
aber in einer anderen Version. Und man möchte die Packages
eigentlich nicht direkt auf der Maschine mit
den
nativen Dingen installieren,
sondern man... Es ist immer
ganz schön, wenn man das isolieren kann. Dann kann man alle
Dependencies installieren, die man für das
Projekt braucht, ohne dass man irgendwas anderes kaputt
macht. Und dafür kann man Virtual
Environments nutzen.
Es gibt auch einen anderen Ansatz, aber die meisten
Tools benutzen Virtual Environments und erstellen
dann eben kleine isolierte Umgebungen, wo man dann
über PIP oder Conda, wie auch immer sich die
Pakete installieren kann. Und Python hat zwei Tools,
die wirklich nur für Environment Management gedacht
sind. Das ist einmal Venv. Das kommt auch direkt mit,
wenn man Python installiert. Das braucht man also nicht
zusätzlich installieren. Und Virtual Env. Ich habe beides
schon benutzt. Es ist beides recht ähnlich. Virtual Env kann
auch ein paar mehr Dinge machen als
Venv. Aber
ich könnte da jetzt nicht
eins groß über das andere empfehlen.
Vor allem, weil wenn man
noch mehr machen möchte, beispielsweise man
ein Package erstellt, dann ist es häufig hilfreich,
eins von den Tools zu benutzen, die eben auch
noch andere Dinge können. Aber ich
habe häufiger schon mal, wenn ich einfach nur ein Virtual Environment
erstellt,
erstellen wollte, Venv benutzt oder Virtual Env,
um das schnell machen zu können.
Also ich benutze versuchst dann immer noch Virtual Env
Wrapper, weil das halt dann irgendwie
nur so drei oder vier...
Ja, da gibt es ja noch ein paar interessante Shell-Aliasse, die man dann
zusätzlich hat. Ehrlicherweise
auf Windows, ich muss ja, wenn ich Windows benutze,
ist das ja mal Quatsch. Da gab es irgendwie Virtual Env Wrapper PowerShell,
das irgendwie fürchterlich war. Und ich habe es mir einfach selber geschrieben, was
eigentlich nur ein Wrapper um Venv ist. Und du willst halt
sowas haben wie MK Virtual Env oder
RM Virtual Env oder LS Virtual Env,
um halt deine Virtual Envs anzuzeigen, die du hast
und die du halt einfach dann aktivieren kannst mit
sowas wie WorkOn. Also ich finde das Schönste
an Virtual Env Wrapper ist WorkOn.
Du gehst halt einfach in dein Projekt
und gibst ein WorkOn in der Shell
und die Env ist aktiviert, ohne dass du irgendwas machen musst
und das ist halt immer convenient, das zu tun.
Ah ja, benutzt aber einer von euch
eigentlich, genau, fürs Erzeugen
oder Verwalten von Virtual Envs PyEnv,
weil das könnte man ja auch machen.
Also ich habe es... Ja,
nein, also ich benutze es nicht mehr.
Ich habe es noch nie benutzt dafür.
Okay, ich habe es mal dafür benutzt und
mache es aber nicht mehr, weil
das ist...
Damit hatte sich
das erledigt, als ich dann von ZSH
auf Fisch umgestellt bin.
Die Shell und jetzt verwende ich halt zum Verwalten
der Virtual Envs Virtual Fisch,
was ich auch noch empfehlen kann, wenn man die Fischshell hat.
Ja.
Genau, nee, verwende ich auch nicht mehr.
Ja genau, also ich benutze tatsächlich für Erstellen
von Virtual Envs meistens Poetry.
Da wird gleich ein großer Aufschrei kommen,
weil da gibt es große Diskussionen um dieses Tool
und ich benutze es tatsächlich immer noch und
ja, weil das in den Projekten, ich eh eine
PyProject Hummel habe, wo die Dependencies drin definiert
sind, dann mit Poetry relativ easy geht
und wenn ich mal selber eine eigene Env kurz
brauche, dann einfach mit dem Virtual Env Wrapper
einfach mkvirtualenv Name
work on, fertig.
Ja, das ist auch das, was ich am meisten gesehen habe.
Wobei für Einsteiger, die jetzt
wirklich noch nie ein Package gemacht haben,
ist das häufig nochmal schwierig,
wenn man dann da plötzlich so ein PyProject
Atommel-File rumfliegen hat und überhaupt
nicht weiß, wirklich was das macht und wofür man
das braucht. Da kann es schon ganz hilfreich sein,
einfach mal nur diese Tools zu benutzen.
Genau. Wie Venv. Ja, das ist,
über die PyProject Hummel müssen wir glaube ich später auch nochmal sprechen,
weil es da ja auch verschiedene Ideen gibt, wie man da
strukturiert und da bin ich auch mit so Sachen, die Poetry
zum Beispiel macht, nicht so einverstanden und
da gibt es ja so ein paar Peps, die glaube ich, das
relativ besser strukturiert
hätten, glaube ich, ja.
Es gibt auch so ein paar Tools, du hattest ja gerade
einmal gefragt, die nicht nur
Environment Management machen, also natürlich auch die, die
alle Packaging machen, aber es gibt zum Beispiel PipEnv,
das ist auch schon ziemlich
alt, das Tool, was
einem dann auch noch erlaubt, also das sagt
der Name ja auch schon, dass es Pip und
Virtual Env zusammenführt
und das Ganze nochmal ein bisschen
mehr abstrahiert, also noch mehr
Funktionalitäten hat und man darüber auch Packages
installieren kann, habe ich jetzt
relativ komische Dinge.
Weiß ich nicht.
Inwiefern?
Es gab eine Zeit lang
war halt da mal so ein bisschen das Problem, was man
gehört hat, dass
das nicht richtig im Intent wäre oder so,
aber ich glaube, das ist nicht mehr so, das ist inzwischen,
weil es halt auch eins von den Projekten von,
wie heißt der noch,
Kenneth Wrights,
ursprünglich, aber der hat damit glaube ich nichts mehr zu tun.
Hat das abgegeben, also ich glaube, das war mit so einer der Gründe,
wo man gesagt hat, so, äh, ii, aber
ja, wenn das jetzt in anderen Händen
liegt, müsste man das nochmal angucken.
Ja, okay, hat auch noch
so eine look-up.
Ganz viel in diesem Bereich,
da kommt es aber auch darauf an, was man gewohnt ist,
was die anderen benutzen, wenn man irgendwann
anfängt, ein Tool zu benutzen, beispielsweise, wie du das
jetzt mit Poetry genannt hast,
dann gibt es selten Grund, plötzlich auf ein Tool wie PipEnv
umzusteigen, weil
ja, also ich könnte jetzt verstehen, wenn man
dann ein anderes Packaging-Tool benutzt, also eins,
was auch mehrere Dinge kann, aber dass man
zurückgeht auf ein Tool, was weniger
kann und dann vielleicht nochmal mehr Komplexität
hinzufügt, weil PipEnv zum Beispiel
hat so eine eigene Konvention, das
ist eben schon rausgekommen, bevor
es den, ähm, Python
Enhancement Proposal gab zu
PyProject.toml-Files, dass man die benutzt
und die haben eben auch so einen eigenen
Weg, das zu machen, also
wenn man PipEnv benutzt hat, hat man plötzlich
ein Pip-File noch da und auch ein
Pip-File.log, ähm,
das finde ich teilweise
schwierig, weil
das nochmal wieder
was anderes ist.
Also ich glaube, Leute, die PipEnv schon benutzt
haben und sich damit auskennen, für die ist das
ganz nett, aber ich würde jetzt
ich persönlich niemandem empfehlen, sich das
anzugucken, sondern dann einfach direkt ein Tool wie
Poetry zu benutzen oder Rye,
Hedge, wie auch immer.
Was haltet ihr von PDM? Oder was hältst du von PDM?
Ich hab's
selbst noch nie in einem Projekt benutzt, also
in einem Kundenprojekt. Ich hab's mal selbst ausprobiert.
Darum kann ich da nicht so viel
dazu sagen. Ich hab's natürlich mir
angeschaut für den Talk und fand's jetzt ganz
cool. Ähm, aber
ich kenn auch Leute, die darauf schwören, also
die das richtig gut finden.
Ähm, man muss zu PDM aber sagen,
ich hatte das ja vorhin kurz erwähnt, dass die
meisten Tools Virtual Environments benutzen
und PDM ist eins der wenigen Tools,
die einen anderen Ansatz fahren.
Und zwar benutzen die so, benutzt
das sogenannte Local Environments.
Das war auch ein Pep, der jetzt aber abgelehnt
wurde. Ähm, und
ich glaube, am Anfang gab's darum auch
sehr viel Interesse an dem Tool, dadurch, dass es halt diesen
anderen Weg benutzt.
Bin mir nicht sicher, was jetzt passiert, dadurch, dass es abgelehnt
wurde, ob das irgendeinen Unterschied macht.
Da diese Local Environments.
Ich glaube, es gibt auch so ein paar
Tools, die das so machen.
Ja, okay. Ich kann das gar nicht.
Ja, also ein Ding,
was mir nicht so klar war, als ich
äh, also früher und jetzt,
äh, dass das, dass es viele
Dinge gibt, die sehr unterschiedlich, also ich meine, das ist natürlich
schön, wenn man ein Tool hat, das irgendwie alles macht, aber
ähm, und
das war auch einer der Gründe, warum ich irgendwann mal
äh, auch eigentlich recht begeistert war von
Poultry, dass ich das Gefühl hatte, ich muss
nur noch diese eine Geschichte irgendwie
benutzen und kann damit eigentlich alles machen, was ich
so irgendwie tun will.
Und dann merkt man aber mit der Zeit so, naja,
so richtig, so
leider sind die Sachen doch sehr unterschiedlich,
also so unterschiedlich, dass man sich dann doch dafür interessieren
muss, dass diese Abstraktion halt anfängt,
äh, zu leaken und dann, äh,
dann wird's halt hässlich.
Für mich jedenfalls. Also ich find Poultry super, weil
es halt drei Sachen für mich macht, und das sind Dependencies
zum Projekt dazufügen, Dependencies für ein Projekt,
Dependencies für ein Projekt installieren, Dependencies für ein Projekt updaten,
und das ist so das Hauptding, für das ich's benutze,
und es ist trotzdem total nervig,
und es geht immer wieder kaputt.
Schreibst du Libraries, wo du dann
Pakete erzeugst? Nein, genau, das nicht, also weil
das ist nämlich genau der Punkt, wo ich wahrscheinlich, weiß ich
nicht, ob ich Poultry für mich nehmen würde, ich hab ja
irgendwie Flit oder Hedge irgendwie besser dafür geeignet,
aber da kommen wir vielleicht auch noch drauf, wenn wir Packaging
besprechen, ähm.
Ja, weil ich würd sagen, solange man nur
Projekte hat, wo man halt
andere Abhängigkeiten reinzieht, und die man dann
halt irgendwie, äh, irgendwo installieren
oder irgendwo hindeployt und so,
da funktioniert das ganz gut, aber sobald man halt
eigene Libraries hat, wo man, äh, irgendwie
Pakete erzeugen möchte,
dann beißt einen das so ein bisschen,
dass da die Anforderungen einfach völlig anders sind
als, äh, und, ja,
also da find ich halt zum Beispiel, also da fand ich
halt Poultry macht da Ding, äh,
da hat mich sozusagen
kalt erwischt, dass, ähm,
dass die, äh,
dass das halt zwei sehr unterschiedliche Use Cases
sind, und ich dachte, ich könnte das halt für beides
gleich verwenden. So ein Paarstellenstrich hat die Kaputte
oder sowas, dann will man halt irgendwie den Pfad
für Poultry Home setzen, und dann installiert es aber
trotzdem irgendwo anders, andere Dinge hin
und sowas, das ist halt einfach total nervig
und... Ja, das Schlimmste war, dass, äh,
also bei meinem Anwendungsfall,
das hab ich wirklich nicht gewusst, äh,
und das hat halt, äh, Sachen draußen
kaputt gemacht, äh, ist halt, dass Poultry
per Default, was ja vielleicht
okay ist für Applikationen, die man irgendwo hindeployt,
eine obere, äh, eine obere Schranke
für Abhängigkeiten hat. Das kannst du aber
einstellen. Klar kann man das einstellen, ich hab's nicht gemacht.
Und wenn du jetzt ein Paket baust,
und hast da implizit obere Schranken drin,
für die Abhängigkeiten, dann ist
das für Leute, die sich, die
dein Paket als Abhängigkeit haben, halt total blöd.
Ja, obere Schranken, also da,
da war ich erst anderer Meinung, und, ähm,
das macht im Data Science Umfeld, macht das unheimlich viele,
und auch unheimlich viele Pakete, die halt obere Schranken drin haben,
und, äh, es gab diesen sehr länglichen
Blogpost dazu, den du mir geschickt hast,
äh, den wir auch nochmal verlinken können, der mich
auch überzeugt hat zu sagen, dass das wahrscheinlich eine ziemlich
doofe Idee, äh, überhaupt so eine obere Schranke
zu haben.
Interessant, dass es mir noch nie begegnet, das Problem
Ja, du,
im Data Science Umfeld tatsächlich öfter, und wenn du dann
irgendwelche neuen Versionen hast, und die
sagen, na, ich will aber nur bis Python
maximal 3.10 gehen, und du willst aber 3.11 nehmen,
dann musst du das halt irgendwie umbauen, oder sowas,
das ist halt schon ätzend.
Ja, eigentlich gar nicht so sehr dabei, sondern
eher so bei, äh, irgendwelchen
Third-Party-Geschichten, also man hat halt irgendwie
eine, irgendeine
Crypto-Library oder so, die man
halt als Abhängigkeit verwendet, wenn man irgendwas,
wenn man die für irgendwas braucht,
und dann, äh,
äh, sozusagen hat man eine implizite
obere Schranke auf der, auf
diese, auf eine Version von diesem Paket,
und jemand installiert
jetzt eine Library, die man selber irgendwie
gebaut hat, äh, und hat
aber noch eine andere, und jetzt sagt die eine
irgendwie, ich brauch aber Abversion so und so, weil
die hat halt irgendwie so eine, äh,
Funktion, die das halt benötigt, und
mein Paket, ohne dass ich das weiß, sagt,
aber ich kann nur bis zu der Version, und dann
kriegt der halt einen Konflikt. Ja, genau. Und kann's
nicht mehr installieren. Und das ist gar nicht
deswegen, weil es einen echten Konflikt gibt, sondern deswegen, weil ich
einfach nur in den Default-Einstellungen nichts geändert habe. Ja, genau.
Und das ist halt, äh, genau.
Und wenn dann Leute sagen so, ähm, dein,
dein Library ist, äh, die macht irgendwie
hier bei mir Dinge kaputt, dann, äh,
ja, das ist halt nicht so schön. Genau, und das, also im Datastandort
hatte ich das recht häufig bei irgendwie Machine Learning-Paketen,
dass du halt tatsächlich hingehen musstest, müsstest du in den Paketen
die Requirements so anpassen, dass es halt irgendwie
funktioniert, und gucken, ob's dann geht, was man halt dann auch nicht so genau
weiß. Aber das, äh, ja.
Ja.
Das, ja. Habt ihr das mal mit anderen Tools
ausprobiert, ob das Problem dann auch besteht?
Ja, besteht auch mit dem, damit.
Ähm, also,
apropos Tools, ähm, Jochen, du meinst Pip-Tools
jetzt für deine Environments?
Genau, also ich verwende jetzt unterschiedliche Dinge,
also für diese beiden unterschiedlichen Use-Cases, also wenn ich
halt eine Applikation habe, wo ich
Abhängigkeiten, also wo ich halt auch sowas wie
Log-Files, bei einer Library habe ich
ja keinen Log-File. Aber bei einer
Applikation hätte ich natürlich schon wieder einen Log-File, sodass
halt alle Entwickler irgendwie, dass ich halt weiß,
äh. Was nochmal ein Log-File ist. Ja, muss man
auch mal finden. Also ein Log-File
ist normalerweise, pinnt halt die
Dependencies und insbesondere den, den
Dependency-Grafen halt mit, für deine
Dependencies, dass halt klar ist, dass so
die Versionen und die Abhängigkeiten dieser
Pakete, die du da benutzt, auch
ähm, gepinnt sind und
meistens hashtest du die noch, das heißt, du kannst halt sehen,
ob irgendwelche Änderungen da sind, also aus der Qt-Perspektive
gar nicht so interessant. Ja, ob das, was man runtergeladen hat,
auch tatsächlich, äh, das ist, was man haben
wollte. Genau. Genau. Und
ja. Also es führt halt dazu, dass
wenn zwei Leute, ähm, sozusagen
das, äh,
Virtual-Env mit allen Environments,
äh, äh, äh. Nach dieser Anleitung,
werden installiert. Kriegen die dasselbe. Kriegen sie genau
das Gleiche. Genau. Und haben nicht unterschiedliche
Versionen von Paketen. Genau, also das ist das Hauptproblem auch,
also klassisch ist ja Requirements-TXT.
Genau. Und das, da wär's nicht so.
Da sind halt diese ganzen Subdependencies nicht enthalten
und es kann halt sein, dass wenn man Requirements-TXT
irgendwie ein Jahr später installiert, dass dann irgendwas gebrochen
ist, weil sich da. Genau, man. Abhängigkeiten
geändert haben. Man erzeugt die Requirements-TXT,
sechs Monate später kommt ein Entwickler dazu
und installiert nochmal und sagt dann, hä, das
lässt sich gar nicht mehr installieren, weil. Ja, genau.
Irgendwelche Konflikte auftreten oder es verhält sich anders.
Und das ist natürlich etwas, was man nicht haben will.
Dafür braucht man unbedingt Blog-File-Teil. Und deswegen
also diese Blog-Files sollten eigentlich meiner Meinung
nach auf jeden Fall Teil von so einem Projekt mit
sein. In welcher Form auch immer.
Ja, wird glaube ich auch immer empfohlen.
Von einer Applikation, aber eben bei einer
Library halt nicht, weil da weiß ich ja gar nicht,
was installiert wird. Ja.
Und genau, für den Anwendungsfall
nehme ich halt,
also
eine Anwendung, die ich deploye, nehme ich halt Pip-Tools
und für den, ich hab ein
Paket, wo ich ein Wheel oder irgendwas
sonst wie ein Paket veröffentlichen möchte,
nehme ich halt Flit, was
jetzt, ich gucke
manchmal so nach Hedge rüber,
bisher hatte ich noch nicht so richtig den Grund
irgendwie umzusteigen.
Ja, wenn Flit für dich funktioniert, das ist auch glaube ich
das Wichtigste, was man von dem Ganzen mitnehmen
kann. Packaging ist zwar
super messy in Python,
also es ist total schwierig
da einzusteigen, weil Python eben
nicht designt wurde mit einem Tool,
was es alles kann, wie das bei Rust ist,
weswegen ja viele Leute sehr begeistert sind von
Rust, vor allem die Python kennen, da läuft
das sehr einfach, da hast du, hat man
Cargo, was man benutzen kann
für das Packaging und dann braucht man sich
nicht die Gedanken machen über diese ganzen anderen Tools
und
verschiedene Tools bei Python lösen eben verschiedene
Probleme und Flit ist super,
wenn man ein reines Python-Paket hat und das einfach
nur bilden
möchte, also wenn man irgendwie ein Wheel-File braucht und
das vielleicht dann noch publishen will und wenn das
für einen selbst funktioniert, dann wunderbar, da kann man
das wirklich gut verwenden.
Ich habe gerade noch daran gedacht, mit den Log-Files,
was ihr gesagt hatte, mit diesem Unterschied zwischen
abstrakten und konkreten
Abhängigkeiten,
das kann man vielleicht auch noch mal
ganz gut in Verbindung mit dem PyProject-Hommelfile
erklären, weil wenn man ein Paket
baut, hat man eben PyProject-Hommelfile,
wo die ganzen, ja,
wichtigen Dinge über das Paket drinstehen,
das sind so Sachen wie
der Name, wer der Autor ist, aber
eben auch die Dependencies, dann kann man da
für manche Tools auch genau sagen,
wie die konfiguriert
sein sollen, sowas wie Black zum Beispiel,
wenn man Formatting benutzen möchte.
Man kann da auch Skripte definieren, also man kann
quasi super viel reinschreiben, dieses
PyProject-Hommel, also die ganze Konfiguration löst halt
diese Placerer an Konfigurations-Files
ab, die dann irgendwo im Projekt-Root
rumfliegen müssen, ja.
Ja, und man,
die Dependencies, die man da reinschreibt, sind aber
möglichst, ja, grob
gehalten, würde ich mal sagen, also da kann man
Ranges angeben, welche
Paketnummern gut sind, aber man sollte
nicht die, auf genau die Version pinnen,
die man haben möchte, wofür dann die
meisten Tools eben automatisiert so ein
Log-File erstellen, wie ihr das gerade beschrieben habt,
sodass man das auch noch mitgeben
kann in seinen Repository
oder Package, sodass alle
genau das gleiche Setup
reproduzieren können.
Setup ist, glaube ich, ein gutes Stichwort. Ich glaube, früher
hat Python das halt mit Setup-Py gemacht und
Setup-Tools,
dann war das halt in Python und halt nicht in dieser
deklarativen Tummel.
Ja, die Geschichte davon ist auch,
also da gibt es ja noch sehr viel mehr, es gibt auch noch
Dist-Utils und ach, was ist der Teufel?
Ja, aber genau, also von
der Setup-Py wollte man eigentlich wegkommen,
weil irgendwie, naja, gut, viele Leute
haben immer nur ihr altes
Setup-Py, was sie sich irgendwann mal irgendwie hingeschrieben haben,
halt kopiert und
das war halt so ein Problem,
deswegen, ja, musste
man quasi beliebig lange abwärtskompatibel bleiben
mit allem und
inzwischen
sollte ja eigentlich für fast alles, was
man tut, Setup-CFG ausreichen
irgendwie,
aber ja, das ist alles ein
It's a mess.
Ja, genau.
Es ist auch eben überraschend, finde ich, also das
ich habe gerade mal das PEP geöffnet
von, das ist
518, wo es darum geht, dass
pyproject.tummel eingeführt wird, das ist von
2016, also es ist schon echt eine Weile
her und trotzdem begegnet mir das immer wieder,
dass Leute noch Setup.py benutzen,
obwohl inzwischen das schon so weit verbreitet
ist, dass man eine pyproject.tummel
Datei hat, in der
man im Tummel-Format eben definiert,
wie das Paket aussieht und welche
Abhängigkeiten es hat.
Also was ich so ein bisschen anstrengend finde, ist, dass
es halt keine Referenzen gibt in diesen Tummel-Files, dass
du halt dann Redundanzen hinkriegst, wenn du mehrere
Male diesen Namen verwenden willst in unterschiedlichen
Sachen oder sowas, was manchmal so ein bisschen
schade ist, aber gut,
es gibt Schlimmeres, als dann
zweimal irgendwie den Projektnamen hinzuschreiben, aber
ja, also ich mag die pyproject.tummel
sehr gerne, ich benutze sie halt auch für alles und
ich glaube, mittlerweile sind die meisten Tools durch
irgendwelche Tricks auch dazu zu bringen,
nur noch diese pyproject.tummel zu nehmen,
also Flake oder so.
Das ist halt so ein Kandidat für, nee.
Ja, genau, aber das geht auch, da muss man halt
ein extra Paket installieren, dann geht das, das gibt halt
so ein Fork davon quasi.
PyTest oder so ist halt auch
sehr schön darüber einstellbar, MyPy,
Ruff
und deine ganzen Tools halt, ne?
Linting und sowas.
Die Skripts
finde ich auch sehr interessant, weil
da gibt es ja auch verschiedene Sachen, das noch zu lösen.
Welche Skripts man irgendwie einhängen will.
Ja, das finde ich auch ganz schön.
Ich hatte das auch jetzt gerade im Kunden
Projekt wieder, dass jemand
Makefile benutzen wollte, um
bestimmte Kommandos, die man häufig
ausführt, runterzuschreiben
oder es zu vereinfachen, weil
der Person gar nicht bewusst war, dass man das auch
im pyproject.tummel-File definieren kann.
Also wenn man zum Beispiel immer
Python-M-Unit-Test-Discover-Test
schreibt, dass man
das einfach abkürzen kann, indem man
in der pyproject.tummel ein kleines
Skript quasi definiert und dann
sagt, dieser Befehl
soll ausgeführt werden, wenn du
Hedge, jetzt als Beispiel, Hedge ist eins
von diesen Packaging-Tools und wenn du
Hedge-Run-Test
schreibst in dein Terminal, dann wird
eben dieser Befehl ausgeführt.
Finde ich unheimlich
praktisch. Habe ich schon sehr viel
benutzt, benutze ich auch sehr viel.
Ich habe mir meinen eigenen Webpack geschrieben, weil
bei mir ist es dann cc, weil
ich habe meinen c-Compiler, die
linkt und dann einfach cc-up,
cc-start, cc-test,
crawl-command. Aber man muss
dafür das Paket quasi installieren,
im aktuellen Environment.
Genau.
Ja, aber das ist halt sowas,
wenn ich jetzt in einem Projekt bin,
also sagen wir mal, ich habe ein Django-Projekt oder so,
dann installiere ich das ja gar nicht als Paket oft.
Da ist halt wieder so
diese Unterscheidung, wenn ich ein Paket entwickle,
okay, dann habe ich das normalerweise auch immer
in einer editierbaren Version
installiert im aktuellen Environment, aber
das ist wieder diese Unterscheidung zwischen
Libraries und
install-e oder sowas, also
editable installiert ist
eine der Features, die nicht jedes von
diesen Tools unterstützt. Ja, da hatte
Poetry auch lange Probleme mit, ja.
Ja.
Aber genau,
damit geht das gut. Ja, ich bin inzwischen also
gerade bei
ich bin bei einem eigenen
Skript, das ich halt in alle
Projekte reinlege oder so,
weil
es oft auch so ist, wenn man das zum ersten Mal ausführt,
dann kann ich halt so Dinge machen,
wie ich mache halt ein try-except
um Imports und wenn die da nicht da sind,
dann gucke ich halt, ob ich irgendwo das Log-File
finde und dann installiere ich das erstmal,
erzeuge ein Virtual-Env und mache halt so,
sodass halt, wenn jemand, auch wenn jemand keine Ahnung
hat, einfach irgendwas ausführt, dass es dann
trotzdem funktioniert. Das geht halt, wenn man ein eigenes Skript hat,
relativ gut, aber ansonsten
wenn man den Leuten dann noch erklären muss, nee, du musst erst das Paket
installieren und dann so, welches Paket?
Ja, das, okay, und dann ist es halt immer noch mal
eine Hürde. Ja.
Ja, ich weiß es nicht. Ich habe da auch keine gute Lösung für.
Ich habe gerade
noch daran gedacht, dass es vielleicht auch ganz hilfreich
ist, einmal zu erwähnen, dass diese
Tools, die wir jetzt gerade schon genannt haben,
sowas wie Hedge oder Poetry, PDM,
Rye, dass die für
ein dieses Virtual-Environment-Handling
machen, also dass man da gar keine Virtual-Environments
mehr selbst erstellt, sondern man
installiert das Tool und dann kann man beispielsweise
sagen, beispielsweise sagen Hedge
run und dann Python
main.py oder was auch
immer und dann
lässt Hedge dieses Skript
innerhalb eines Virtual-Environments laufen
wo all diese Dependency
die man im pyproject.toml-File definiert hat,
schon installiert sind.
Sprich, man muss das nicht mehr manuell erstellen,
dieses Virtual Environment.
Das wird dann für einen gemacht.
Mhm.
Ja, dann, also Pultree zum Beispiel,
kann man halt auch dann konfigurieren,
dass halt alle WEMFs in einem bestimmten Ordner liegen,
wenn man das gerne hätte.
Oder dass die halt im Projekt liegen.
Also das gibt halt diese zwei Varianten.
Ich weiß nicht, wozu ihr da tendiert.
Vielleicht auch ein bisschen die Frage,
ob man ein Dev macht,
wo man halt zwischen den WEMFs vergleichen will
oder ob man das halt in ein Pod macht,
wo man das vielleicht direkt ins Projekt legt
oder irgendwo nach Opt oder ich weiß nicht.
Ja, also man kann...
Häufig einfach den Default benutzt.
Mhm.
Also ich mache, ist unterschiedlich.
Für Entwicklungen lege ich die ganzen Virtual Envs
in ein Verzeichnis,
damit ich halt nur bei einem Verzeichnis sagen muss,
dieses Verzeichnis bitte nicht backuppen.
Ansonsten müsste ich eine Regel haben,
die das halt für alle,
die halt immer rausfindet,
was ist das Virtual Env in einem Projekt
und dann das dann halt nicht backupt.
Was auch geht, aber ist halt komplizierter.
Und wenn ich mich dann an diese Regel selber mal nicht halte,
dann wird halt ein Virtual Env gebackupt,
was halt doof ist.
Ja, also ich habe aber tatsächlich schon gesehen,
dass tatsächlich sogar die WEMFs Teil der Version Control sind.
Ja, das ist natürlich...
Nee, also das würde ich auch nicht machen,
aber das habe ich schon gefunden,
weil die Leute halt irgendwie die brauchen,
reproduzierbar auch irgendwie auf ihren Systemen,
dann halt tatsächlich einfach die WEMF auschecken
und dann haben sie die schon,
ohne dass sie diesen ganzen Hustle machen müssen.
Oder die wird halt irgendwie gesippt und halt dazugelegt,
weil man die dann für alte Versionen
halt einfach dann dabei hat und die funktioniert direkt.
Und wenn man dann halt jetzt nicht den Python nur gelinkt hat,
sondern das halt als hart dahingeschrieben hat,
dann könnte das sogar funktionieren.
Also...
Ich habe Zweifel.
Ja, gut, aber das ist halt wieder genau so ein Punkt,
wo wir halt merken,
es gibt halt ganz, ganz viele verschiedene Lösungen
für dieses Problem,
wie laufe ich denn überhaupt eine Python an,
die alle nicht so richtig gut funktionieren und so.
Ja.
Alle Probleme haben an irgendwelchen Edge Cases.
Also es gibt, das ist tatsächlich,
also das Beispiel Rust ist da, glaube ich, echt ein guter.
Also weil du machst Rust ab und hast dann Cargo und sowas.
Ja, aber man kann halt,
das wird ja dann auch oft vorgeschlagen.
Warum machen wir es nicht einfach wie Rust jetzt sozusagen
in der Python-Welt und dann sind wir dieses Problem los.
Das funktioniert halt nicht, weil Python halt so alt ist
und es so viele Dinge gibt.
Also tatsächlich größere Teile des Ökosystems würden,
wenn du sagst, okay, das ist jetzt der Weg,
wie wir das machen, halt einfach nicht mehr funktionieren.
Und dann kannst du es halt eigentlich auch nicht machen.
Also einen Plan verpassen.
Also zum Beispiel den ZRPY-Support einstellen.
Das haben auch Leute schon angedacht oder probiert.
Und dann...
Bei den Diskussionen kamen wir raus,
nee, das ist unmöglich, das geht nicht.
Kann man nicht machen.
Also bei Python 4 dann.
Selbe Problem, ja.
Das will auch keiner mehr machen.
Das will auch keiner machen.
Das ist so ein harter, solche harten Kompetibilitäten.
Das wird nicht mehr passieren, glaube ich.
Ja, es ist, aber genau.
Also auf Produktivgeschichten, da mache ich das so,
dass ich das Virtual Env in das Projekt selber mit reinlege.
Einfach deswegen, weil ich dann sozusagen alles an einem Platz habe
und halt auch, wenn ich es dann entferne,
auch nur ein Verzeichnis entfernen muss.
Und nicht noch gucken muss, oh, da gibt es noch das Virtual Env.
Oh, da gibt es ja noch die Datenbank unter Auer.
Da gibt es noch dieses Dings, was ich auch noch mit entferne.
Sondern dann entferne ich das eine Ding und dann fertig.
Ja, also ich habe das tatsächlich unter Opt.
Und dann halt die Python-Sachen alle da an einer Stelle,
die für das Projekt da sind.
Okay, auch interessant, ja.
Und dann habe ich halt quasi das Projekt,
also den Code vom Projekt und den Code von dem,
was für das Projekt zum Lauf notwendig ist.
Also zwei Sachen, aber ja.
Ja.
Ich habe gerade noch daran gedacht,
Hedge zum Beispiel ist eins der Tools,
die ich recht häufig benutze.
Einfach auch nur, weil ich,
weil ich irgendwann damit angefangen habe
und das ganz nett finde.
Und das hat so ein tolles Feature für die Virtual Environments,
dass man im PyProject.toml-File eben auch definieren kann,
deklarativ, welche verschiedenen Virtual Environments
man haben möchte.
Und ich habe beispielsweise häufig eins für Styling,
also wo man, was dann Black über alle Sachen laufen lässt,
wo dann, also da sind da die Dependencies nur,
wie Black, Rough und Ähnliches installiert.
Und auch die Skripte dafür.
Und dann habe ich ein Virtual Environment
für die Documentation.
Ich benutze zum Beispiel Material for mkDocs,
wo das dann installiert ist.
Und dann kann man halt wirklich ganz strukturiert sagen,
okay, diese verschiedenen, ja, Anwendungsfälle
oder das mache ich in meinem Workflow
und dafür brauche ich nur diese Dependencies.
Und dann kann man das wirklich schön organisiert runterschreiben,
PyProject.toml.
Das finde ich irgendwie total angenehm,
weil das so viel besser nach außen kommuniziert.
Potpourri hat das auch irgendwann eingeführt als Groups.
Ah, okay.
Und tatsächlich, also du kannst halt die Gruppen optional machen halt
oder halt nicht.
Also die nicht optionalen Gruppen sind halt die,
die absolut notwendig sind damit,
wie die Anwendung läuft.
Und halt solche Sachen wie Docs oder wie Tests oder sowas
können halt eigene Gruppen haben.
Da hatten wir mal mit Johannes drüber gesprochen.
Johannes meinte, totaler Quatsch.
Du brauchst eigentlich nur zwei.
Und das ist Def und Prot.
Def und Prot, ja.
Kann man auch vertreten.
Ja, aber es ist halt die Frage,
braucht man so einen Fall, wo man nur linden will
oder wo man nur Docs angucken will oder so.
Ja, also mein Argument dafür wäre halt auch genau,
weil ich habe, also oft hat man dann implizit ja doch mehrere.
Zum Beispiel, wenn man sowas wie Precommit Hooks verwendet.
Bei Precommit kümmert sich ja auch wieder selber
da drum.
Und dann hast du es aber implizit irgendwie.
Und es wäre natürlich vielleicht schöner,
das explizit irgendwo stehen zu haben,
wo das, ja.
Ja, Precommit MyPi ist zum Beispiel so ein Kandidat,
der unheimlich nervig ist, weil das halt, ja.
Genau.
Also,
also genau,
also ich würde sagen,
wenn man nur Def und Prot haben will,
dann schafft man das nicht,
weil man hat ja zumindest noch das für Precommit.
Und das heißt,
dann hat man nochmal einen Ort, wo man das pflegen muss.
Das steht ja auch nicht in der PyProject Tommel,
sondern es steht dann auch wieder in dem Precommit Jammel.
Und, äh, Jammel, Uwe.
Das ist sehr mäßig.
Bei mir sind es halt so Gruppen, die sind alle optional,
die ich alle per Default dann wieder copy und paste.
Wo halt dann sowas drin ist,
wenn eine Postquest benutzt wird,
dann mach doch bitte diese Gruppe noch dazu.
Und wenn irgendwie Authentifizierung benötigt wird,
dann mach doch bitte diese Gruppe noch dazu.
Und wenn, ja, so Dokumentationen,
dann muss halt alle die...
Okay, an der Stelle würde ich sagen,
beschränk dich doch bitte auf Def und Prot.
Kann man denn bei den Gruppen in Poetry
dann auch Skripte für diese Gruppen,
definieren?
Ähm, nicht, dass ich wüsste.
Aber vielleicht vertue ich mich auch alle.
Ja, also Poetry hat eh immer so ein bisschen so Probleme
mit so dann Sachen wieder abreißen oder sowas.
Oder wenn du halt irgendwie ein Update
von einem Major Python machst,
dann fliegt Poetry oft auf die Nase.
Das ist halt fürchterlich.
Vielleicht ist das jetzt neu besser.
Also auch so ein Ding, ne?
Poetry hat irgendwie zweimal ein Update gemacht,
das so Breaking Changes eingebaut hat,
wo es dann...
Das war halt so sehr, sehr nervig.
Wirklich böse Dinge gemacht hat.
Ja, das war halt der Hauptgrund,
warum viele Leute gesagt haben,
so eine Idee fasse ich jetzt nicht mehr an,
weil sowas geht halt eigentlich nicht, ne?
Genau, ja.
Das habe ich auch total viel mitbekommen.
Also ich habe selbst schon Poetry benutzt.
Das hat für mich immer gut funktioniert
und ich finde es auch ein gutes Tool.
Aber ich habe voll viele Leute,
von voll vielen Leuten das mitbekommen,
die dann einen dieser Breaking Changes mitgemacht haben
und dann gesagt haben, nie wieder.
Also kategorisch benutze ich nicht mehr.
Sowas geht nicht.
Das kann man nicht machen.
Und dann hat man eben auch genug Alternativen,
auf die man zurückgreifen kann,
sodass man Poetry dann nicht mehr verwenden muss.
Also ich sage mal so,
andererseits, das waren halt so ein paar Sachen echt kaputt
und die haben die jetzt gefixt.
So gesehen, ne?
Wenn man jetzt einmal diesen Schmerz hat
und es läuft dann jetzt wieder, warum dann nicht?
Aber ja, ich weiß nicht.
Ich glaube, es war bei vielen auch diese Art und Weise,
mit der es gemacht wurde,
dass zum Beispiel nicht gewarnt wurde davor,
dass bestimmte Dinge dann nicht mehr funktionieren werden.
Ja, ich glaube, der Ton in den Requests
oder in den Issues war auch so ein bisschen rau.
Habe ich das Gefühl gehabt.
Das war, einige Leute fanden das auch nicht so gut.
Poetry ist halt auch so ein Sonderfall,
habe ich manchmal das Gefühl.
Also ich hatte mir so ein paar Kriterien rausgesucht,
um die verschiedenen Tools zu vergleichen,
damit es eben wirklich so ein bisschen unbiased ist
und nicht nur meine persönliche Präferenz mit reinfließt.
Und es gibt ein PEP 621, da geht es darum,
wie man Metadata in der PyProject-Hommel aufschreibt.
Also in welchem Weg.
Und da wurde halt irgendwann ein Standard definiert,
den die meisten Tools vertreten.
Nur Poetry hat da seine Extrawurst und macht das anders,
was ja auch in Ordnung ist,
dadurch, dass sie es von Anfang an anders gemacht haben.
Aber es gibt, glaube ich, seit eineinhalb Jahren
schon ein offenes Issue dazu auf GitHub
und sie wollen es auch irgendwann machen.
Aber sie haben es halt immer noch nicht gemacht.
Und ich glaube, so ein paar Besonderheiten
muss man da schon im Kopf behalten,
wenn man dann Poetry benutzen will.
Ja, also das war auch,
als ich dann irgendwie auch Probleme mit Poetry mal bekommen habe
und dann halt da auch angefangen habe,
Issues aufzumachen und dann mir das Open Issues-Ding mal angeguckt habe,
da dachte ich so, oh, oh, oh.
Also letztlich, glaube ich, ist das einer,
der auch eigentlich als Freelancer arbeitet,
der das halt auch nicht Vollzeit macht,
sondern halt auch so in seiner Freizeit.
Und zu dem Zeitpunkt, wie es heute ist, weiß ich nicht.
Und da waren halt tausend offene,
offene Issues in dem Projekt.
Das ist halt so, okay.
Und einige schon sehr, sehr lange offen.
Und ja, na ja.
Ich meine, es ist ja klar,
dass man das nicht so hinkriegen kann.
Gerade wenn das dann halt viel verwendet wird,
dann wird man halt erschlagen von dem Ansturm von Leuten,
die irgendwas ändern wollen oder irgendwelche Probleme gefunden haben.
Aber ja.
Ist halt für Leute, die das halt noch ein Problem haben.
Ja, das ist ein Open Source Schicksal so ein bisschen.
Ja, ja, natürlich.
Also es, ja, ja.
Wo würdest du denn den Unterschied sehen zu,
zu, zu, zu Hedge oder, oder Rye?
Kann man das irgendwie kategorisieren,
wo da die Unterschiede liegen?
Also ich habe es so ein bisschen kategorisiert
aufgrund der Dinge, die sie tun können.
Beispielsweise ist Rye somit das einzige Tool,
was wirklich alles kann.
Eben auch Python Version Management.
Dadurch, dass es eben nicht in Python geschrieben ist,
sondern in Rust.
Und man dann eben alles in einem Tool machen kann.
Ja, auch so Project Scatboarding oder sowas
mit fürchterlich opinionated und dann so.
Na ja, sorry.
Kein Problem.
Genau, und da gibt es PDM, Poetry, Hedge,
die noch mal so ein bisschen rausfallen,
weil sie, also PDM und Poetry zum Beispiel,
können kein Python Version Management machen.
Man kann einfach PyEnv benutzen,
aber die haben das nicht als eigene Funktionalität drin.
Also dass man irgendwie sagen kann Poetry, keine Ahnung,
add Python Version irgendwas.
Aber sowas gibt es nicht.
Und Hedge wiederum, das ist noch,
also wird auch natürlich sehr aktiv entwickelt.
Aber das kann zum Beispiel,
also jetzt gerade hat es noch keine Package Management Möglichkeiten.
Also man kann jetzt nicht wie bei Poetry,
da kann man ja sagen Poetry add irgendein Paket
und dann fügt Poetry das in die PyProject Tommelfile hinzu
und macht auch, versucht die Dependency-Konflikte zu lösen.
Und das kann Hedge noch nicht.
Der hat immer angekündigt, dass er das noch implementieren wird.
Aber bisher ist es noch nicht da.
Es sei denn, das wurde jetzt die letzten Tage hinzugefügt.
Ich habe es noch nicht gesehen.
Genau, ich glaube, das kommt so,
ein bisschen auf den Use Case drauf an.
Flit hatten wir auch schon besprochen.
Flit ist halt eben wirklich dazu gedacht,
wenn man einfach nur ein Package bilden und publishen möchte
und vor allem ein Package, was keinen C-Code hat oder ähnliches,
sondern wirklich nur Python-Code.
Ich glaube, das ist ganz gut, wenn man sich vorher mal überlegt,
was möchte ich überhaupt machen und dann dementsprechend
sich das Tool raussucht.
Ich muss aber auch sagen, dass bei diesen ganzen Tools
letztlich die persönliche Präferenz und was das Team macht,
auch eine riesengroße Rolle spielt.
Wenn jetzt alle im Team Poetry benutzen,
wird es wahrscheinlich schwierig, Hedge zu benutzen,
weil in der pipe-project.toml-File eben auch das Build-Backend
definiert ist und da steht dann eben Poetry drin.
Vielleicht noch mal ganz kurz zu dem Packaging.
Also ihr wollt ein Paket auf PyPI veröffentlichen.
Das ist so das, was dahinter steht.
Du meinst mit dem Publishen gerade?
Ja.
Ja, genau. Stimmt.
Das kann man vielleicht noch einmal kurz erklären,
dass man bei Packaging zwei verschiedene Schritte dann hat.
Also man kann den Build-Schritt machen.
Das bedeutet, dass ein wheel-File erstellt wird,
was so das Format ist, mit dem das Package beschrieben wird.
Und da ist dann wirklich auch alles drin, was das Package braucht.
Das ist auch letztlich das, was von PyPI gezogen wird,
wenn man pip install was auch immer macht.
Und es wird ein tarball-File erstellt, so .tar.gz.
Und der Publish-Step ist dann,
dass man diese Dateien zu PyPI oder zu irgendeinem anderen Index
veröffentlicht, was man ja gar nicht unbedingt machen möchte.
Manchmal reicht es auch schon, wenn man ein wheel-File erstellt,
was man dann lokal hat, was andere installieren können.
Für Wheels vielleicht noch.
Bei Windows gibt es Goalke, eine wundervolle Bibliothek
von gut gepatchten Wheels für Pakete,
die man sonst bei Windows nicht einfach so installieren kann,
weil man die irgendwie selber kompilieren müsste,
wo dann Kompilierungs-Tools-Probleme auftauchen können oder die es nicht gibt.
Aber auf Windows geht es immer.
Also super tolle Quelle.
Ich merke schon, wenn ich irgendwann mal doch Windows benutzen muss,
dann werde ich auf dich zukommen.
Du hast alle Hexen, die man so braucht.
Ja, das ist einfach so viel Quatsch, die man irgendwann gegenfaut.
Irgendwann geht es dann vielleicht, ja.
Letztens hat jemand einen ganz alten Webcomic repostet
auf Mastodon von 2004 oder so.
Ich weiß nicht, welcher Webcomic das jetzt war.
Man sieht halt irgendwie so Star-Trek-Setting
und im Hintergrund irgendwie Klingonen sich mit so Schmerzstöcken quälen
und einem vor dem Grund sagen so,
oh, ich habe was noch viel, viel Härteres gefunden als Schmerzstöcke.
Irgendwie ist dann hier einfach Windows auf meinem Laptop.
Obwohl man tatsächlich dazu sagen muss, ja,
also mit den neuesten Power-Shades und den neuesten Windows-Terminals
und wenn man das so ein bisschen beherrscht,
kann man auch ohne VSA einigermaßen gut entwickeln.
Es gibt halt so ein paar Sachen, die gibt es noch nicht als Pakete.
Aber für die meisten Sachen geht es ordentlich.
Und mittlerweile würde ich jetzt behaupten, auch für Windows.
Du kennst dich damit sicherlich gut aus.
Ja, ich muss halt damit die ganze Zeit arbeiten.
Also ich würde es auch jetzt nicht unbedingt immer machen wollen,
aber es geht irgendwie schon.
Also ich brauche keinen Docker mehr, wie es vorher die ganze Zeit war.
Dann muss man halt einfach Docker installieren und dann hält das laufend.
Ja, mit Docker geht es natürlich.
Aber auch da hast du natürlich Probleme.
Genau, ja.
Und das wird nach einer Zeit alles ein bisschen langsamer und hässlich.
Aber es geht auch mittlerweile relativ vieles
oder eigentlich alles nativ direkt mit Ausnahmen.
Es gibt so ein paar Pakete, die laufen.
Ansible zum Beispiel.
Zickt halt rum, muss halt doch ein Docker laufen oder auf ESL oder sowas.
Ich habe gerade noch gedacht, mit der Frage von gerade,
mit den verschiedenen Tools, was, finde ich, auch eine große Rolle spielt,
ist, in welchem Entwicklungsstadium die sich befinden,
beziehungsweise wie aktiv die weiterentwickelt werden.
Weil Rai zum Beispiel ist ja ein sehr junges Tool.
Das ist erst, glaube ich, im Mai rausgekommen
und ist auch eigentlich entstanden mehr so als Spielerei, würde ich mal sagen.
Er hat jetzt nicht gedacht, der Auto, dass das jetzt ein Tool wird,
was total viel läuft.
Dass das für viele Leute genutzt wird.
Das nutzen aber voll viele Leute.
Also Rust jetzt hat ja, also Armin Gronacher ist wahrscheinlich der Typ,
der hat Flask gemacht, ne?
Ja, ganz viele, ganz viele Projekte.
Jochen weiß da mehr.
Aber ja, also er macht jetzt gar keinen Python mehr hauptsächlich,
wenn ich das richtig verstehe.
Aber er benutzt halt Python noch manchmal.
Und dafür hat er dann in Rust so eine Lösung geschrieben,
die tatsächlich so ein bisschen nach dem aussieht,
was sich eigentlich die meisten Leute so wünschen.
Aber ja, also ich habe es auch so ein bisschen ausprobiert
und dachte mir so, na, nicht ganz das, was ich brauche.
Was hat dir denn gefehlt, oder?
Also der Stil, wie.
Also vor allem das Project Scaffolding
und wo die Sachen dann liegen und so.
Das ist halt alles opinionated.
Ich meine, ist halt, sein gutes Recht,
er macht halt sein Kram, ist ja voll super für ihn,
aber nicht das, was ich machen würde.
Ich hätte das gerne konfigurierbarer oder so.
Und würde halt das gerne auf meinen Stil umbringen.
Ja.
Ich glaube, das muss man halt auch so ein bisschen im Kopf behalten,
wenn man jetzt sagt, okay, wir benutzen Rai
und wir benutzen das vielleicht auch im Projekt,
sich einmal vor Augen zu führen, okay,
das ist, wird jetzt gerade eben,
von Armin entwickelt und gerade ist es auch sehr aktiv.
Also der bringt da viele neue Releases raus,
aber man weiß ja nicht so wirklich, was damit passiert.
Genau, weil im halben Jahr hat er was anderes vor,
hat einen anderen Job und hat ein neues Hobby oder sowas.
Dann ist halt, liegt es halt darum, wie es halt oft so ist, ne?
Genau.
Und sowas wie Poetry, würde ich jetzt sagen,
ist schon so lange etabliert,
dass es eher sicherer, dass das auch weiterverwendet wird.
Ja, also ich habe,
also weil Jochen halt sagte,
er nimmt jetzt auch kein Poetry mehr
und er macht das alles über PipTools,
auch das mal benutzt.
Und das gefiel mir auch überhaupt nicht.
Ich finde es total fürchterlich,
weil ich, ja, es ist so ein bisschen,
ich benutze es auch nicht pur, sozusagen,
sondern ich verdünne das halt.
Ich habe dann noch so Wrapper außenrum,
die ich dann benutze.
Genau, also man muss sich halt einen eigenen Wrapper drumherum bauen
und das, damit das halt alles wieder irgendwie nett ist und so.
Ja, insofern, ob man das Leuten einfach so zumuten kann.
Ja, also die Frage ist halt auch da, ne,
wenn ich halt jetzt Neulinge im Projekt habe,
irgendwie ein Junior-Dev oder so,
der gerade Python das erste Mal in der Hand hat,
wie erkläre ich ihm das denn jetzt?
Ja, ich habe übrigens das gemacht und das gemacht
und das gemacht und das gemacht und dann hier von oben rein
und von hinten durch, dann, oh.
Oh, das ist aber kompliziert,
dann ist er direkt nach zehn Minuten ausgestiegen
und fängt hier von vorne an.
Das glaube ich auch.
Viele der Tools benutzen auch andere Tools under the hood.
Also, Rye zum Beispiel benutzt Pip-Tools
und natürlich benutzen viele der anderen dann auch Pip.
Also, wenn man jetzt irgendwie Poetry-Add,
irgendein Package macht,
dann nutzt das, glaube ich, Pip oder Pip-X,
ich bin mir gar nicht sicher.
Aber viele von diesen grundlegenden Tools
werden eben auch wiederverwendet
und haben dann aber trotzdem diese übergeordneten Befehle
Poetry-Add.
Ja, also Pip-X ist auch nochmal interessant.
Also, es gibt ja verschiedene Wege zum Beispiel,
dann sowas wie Poetry auch zu installieren.
Man kann es halt einmal selber irgendwie
von Gitter ziehen und bauen,
man kann es halt irgendwie über Pip selbst installieren,
man kann es über Pip-X installieren
oder über, ich glaube, der empfohlene Weg ist,
das Installationsskript zu verwenden.
Ist es immer noch irgendwie,
man nimmt die URL und pipet die nach Curl,
oder zieht die per Curl und pipet die in die Shell oder so?
So ähnlich, ja.
Aber es gibt mittlerweile ein neues Skript und die anderen,
beiden alten Skripte sind auch wieder deprecated
und die sollen wir nicht mehr verwenden
und da gibt es dann irgendeine Warning
und es funktioniert nicht mehr und es geht kaputt.
Also, da gibt es übrigens auch bittere,
also, ja, ich meine, Security-mäßig
immer schon so ein bisschen fragwürdig, das so zu machen.
Aber es gibt halt auch viele Dinge,
die die Leute vielleicht nicht wissen,
die halt echt übel sind.
Selbst wenn man bei Curl halt sagt,
irgendwie benutzt doch bitte SSL,
macht es zuerst nur Request auf HTTP.
Das heißt, wenn ein Angreifer dazwischen sitzt,
der kann das, selbst wenn du sagst,
verwende bitte HTTPS,
wenn du das nicht in die URL dazu geschrieben hast,
Konfigurationsoption gesetzt hast,
kann sich jemand dazwischen klemmen
und einfach den ersten HTTP-Request abfangen
und dann was zurückliefern.
Das heißt, wenn jemand in deinem Netzwerk sitzt,
dann kann er dir da Dinge unterschieben,
wenn du das so machst.
Also, das ist schon, also, naja.
Aber, ja, ich verstehe,
warum Leute auf die Idee kommen, das so zu machen,
weil, ja, die Alternativen sind auch alle nicht so toll.
Gut, also, Rust-Up ist auch per Curl übrigens,
das an der Stelle mal.
Ja.
Ja, also, ist die Frage auch noch interessant.
Habt ihr irgendwelche Pakete,
die ihr in das System Python mit direkt installiert?
Ganz verpflichtend, oder sagt ihr alles,
nein, pur, da kommt nichts dran,
das ist rein Standard-Lib.
Also, ich installiere tatsächlich immer Django.
Ich versuche tatsächlich zu vermeiden.
Also, bei mir ist immer Django drin.
Nee, bei mir nicht.
Also, ich hätte gerne immer Start-Project zum Beispiel.
Ach so, damit du quasi im Template
direkt immer was erzeugen kannst.
Ja.
Okay, ja gut.
Und Rich ist immer drin,
weil ich habe immer so ein paar Sachen in meiner Shell,
die auf Python basiert sind
und da hätte ich gerne immer Rich drin
und Typer hätte ich halt in dem Fall auch gerne drin,
weil ich halt viele Kommando-Talent-Tools,
die ich im System weit benutze, baue.
Deswegen auch da.
Ja, aber das sind dann schon wieder so Dependencies,
die ich dazu packen muss.
Ich habe tatsächlich noch nie Django benutzt.
Warum hast du das?
Also, du hast das gerade kurz erwähnt,
aber nicht so, dass ich das verstehen konnte.
Also, das ist eigentlich nur ein einziger Grund.
Normalerweise, wenn ich ein neues Projekt mache,
benutze ich Django Start-Project,
was quasi den Scaffold macht
und ich benutze dafür mein eigenes Template.
Du kannst halt dann bei Start-Project
einen Pfad zu deinem Template angeben
und damit aber Start-Project
verfügbar ist,
muss halt Django schon da sein.
Und deswegen zähle ich Django einfach direkt mit.
Ja, das ergibt Sinn.
Dieses mit dem Project Scaffolding,
da habe ich auch gerade daran gedacht,
dass die meisten Packaging-Tools,
die haben da auch eben Befehle für.
Das ist vielleicht ganz gut zu wissen.
Also, normalerweise hat man irgendwie
Tests-Directory und Source-Directory
und die meisten Tools,
beispielsweise jetzt Hedge-Poetry,
die haben alle einen Befehl.
Könnte irgendwie Hedge-Init,
nee, Hedge-New und dann sozusagen
so eine Init-Flag beispielsweise,
die erstellen dann das PyProject-Hummel-File
schon mal für einen.
Da sind dann auch viele der Tools schon konfiguriert,
wie Black beispielsweise
und dann auch diese Folder-Struktur.
Also, das kann auch ganz nett sein,
wenn man das nicht alles selbst machen will.
Ja, oder wenn man das mag, ja.
Das ist zum Beispiel so ein Punkt,
wo ich sagen würde,
ich hätte da gerne,
dass er dann ein Template nimmt,
was ich ihm vorgebe,
weil ich nicht mag, wie der es macht.
Und das ist auch der Grund.
Also, es gibt noch ein paar andere Möglichkeiten,
so ein Project Scaffolding zu machen,
sowas wie Cookie Cutter oder so.
Das ist halt,
also ich finde es mittlerweile recht bloated,
wie das haben wir früher halt so ein paar Mal öfter gemacht,
aber da ist halt so viel Zeug drin,
das du halt nie brauchst,
dass du halt alles immer wegschmeißt
und rausschneiden musst.
Total, ich weiß nicht mehr, warum man so.
Wenn man jetzt so ein Standardprojekt,
Django-Cookie-Cutter-Projekt nimmt oder so,
genau, das habe ich früher,
weil früher war das für mich alles so,
oh, es ist so viel Zeug,
was man irgendwie einstellen muss und so,
dann gut, dass da jemand anders drüber nachdenken muss
und nicht ich.
Und inzwischen denke ich mir auch so,
na ja, nee, ich mache das lieber selber.
Aber das Problem ist,
wenn jetzt jemand anfängt,
was empfiehlt man dem?
Ich würde fast sagen,
gar keinen Scaffold,
sondern alles selber bauen.
Ja, aber dann hat er halt eine schwere Lehrkurve
erst mal vor sich.
Und es ist auch Kurve Buchung,
du musst alles aufräumen.
Ich kenne halt auch so Kundenprojekte,
wo die Leute an da irgendwas angefangen haben
und denkst dir so, oh mein Gott.
Ja, Cookie-Cutter ist vielleicht gar nicht so doof,
es gibt ja auch für Data-Science-Templates oder sowas
und vielleicht kann man da auch sein eigenes Template bauen,
ich weiß es nicht.
Ich habe es für Django halt,
Django-Template.
Interessanterweise,
man kann mit diesem Django-Start-Project-Template
das auch missbrauchen für Nicht-Django-Projekte.
Das heißt, du kannst halt da tatsächlich auch andere Projekte,
die gar nicht Django brauchen, haben.
Deswegen habe ich Django tatsächlich am Anfang installiert,
weil ich kann einfach arbiträre Projekte
mit meinem Django-Template bauen,
was im Prinzip sowas ähnliches macht,
wo einfach Ginger ersetzen für irgendwelche Python-Files
und halt Dietrich-Strukturen bauen.
Mir ist fast so wie Cookie-Cutter nicht ganz so mächtig
und ich brauche es halt auch nur so für kleine Sachen.
Ich mache jetzt auch nicht so mega große Dinge, aber ja.
Ja, und ein Problem, was man dabei hat, ist halt,
was ist, wenn sich an dem Basis-Template irgendwas ändert?
Und man möchte jetzt alle Projekte,
die man mit dem Template erzeugt hat,
auf den aktuellen Stand bringen.
Wie macht man denn das?
Das ist eine gute Frage.
Ich bin da gerade dabei, mir was zu überlegen.
Und zwar ist das sowas wie,
du musst dir halt den Commit merken,
von dem du das Template gescaffoldet hast.
Dann musst du einen neuen Brand erstellen,
musst dann den neuen Commit-Hash auschecken,
machst dazu einen Div,
dann hast du halt den Div von deinem Template
und dann machst du ...
dann machst du einen Rebase von deinem ganzen Projekt
auf diesen Div drauf.
So ungefähr funktioniert das.
Und dafür schreibe ich gerade zum Kommando
und das funktioniert.
Okay.
Ja, und das ist aber ...
Ja, ich habe es Cherry genannt.
Ich mache dann CC Cherry
und dann pickt der quasi alle Changes
von meinem Template-Scaffold.
Okay.
Du musst dich halt an zwei Sachen halten.
Zum Beispiel darfst du halt jetzt nicht
an den Sachen, die das Template bereitstellt,
eigentlich rumfummeln.
Ich habe zum Beispiel so Core-Sachen,
die kommen halt immer aus dem Template.
Das heißt, ich muss die immer im Template bauen
und dann picken.
Anstatt, dass ich Sachen selber im Core ändere.
Ich könnte halt nur Sachen dazufügen
und dann sonst wird es halt immer Mesh-Konflikte geben,
wo du halt immer dann manuell rumfummeln musst.
Deswegen würde ich einfach sagen,
meine Konvention ist das dann einfach nicht zu machen,
weil das brauche ich auch nicht,
weil ich habe halt dann E-Apps in der Applikation,
die für die Applikation da sind
und dann machen die halt nur Sachen,
die die Applikation macht
und Core-Funktionalität kommt halt immer dann
aus der Basis raus.
Aber, ja.
Oder auch noch eine Frage.
Genau, gibt es irgendwie,
dass bei diesen ganzen Tools
gibt es da auch so Funktionalitäten für.
Ich habe jetzt irgendwie 30 Reports,
Repositories, die alle relativ ähnlich sind.
jetzt gern zum Beispiel, weiß ich nicht, Poetry Update
oder was auch immer, mal
auf allen ausführen? Gibt es da
Support?
Ich hatte den Fall noch nie, das kann
gut sein. Also habe ich noch
nie ausprobiert, ausprobieren müssen.
Ja, und ich kenne das auch immer so, dass dann Leute sich
ihre eigenen Dinge zum Verwalten von vielen Projekten
schreiben.
Also ich glaube, das ist sehr gefährlich,
weil die Projekte alle so unterschiedlich sind,
da alle gleichzeitig anfassen.
Ja, also zum Beispiel
in der letzten
Jungle Chat Episode wurde Adam Johnson gefragt,
wie er das hinkriegt, dass er irgendwie 70
populäre Repositories
maintained. Oder es gibt ja
Leute, die da ganz viel haben.
Der erste Schritt ist, dass man alle Projekte ungefähr auf den gleichen
Status bringen muss. Und dann kann man
mit Skripten drüber gehen.
Ja, ich habe auch
für die Produktivsachen so ein Ansible-Book,
das halt dann hingeht und einfach Python updatet.
Also zumindest Python Minor oder so, oder Buckmix geht ja noch.
Aber wenn du halt Major, dann musst du
halt eigentlich immer das Projekt auschecken, gucken, ob es geht.
Noch so eine Frage halt.
Wie macht ihr das dann mit Tests für
Produktion, für so Builds in verschiedenen Versionen?
Nehmt ihr da alle Tox? Oder
wie macht ihr das am besten?
Ja, genau. Also ich habe
bisher immer Tox verwendet.
Auch weil es eben meistens schon, wenn man
jetzt irgendwie Hedge oder ähnliches hat, dann
mitkonfiguriert ist. Einfach der einfache
Teil. Ah, okay. Also Hedge konfiguriert Tox auch
direkt mit... Soweit ich weiß,
ja. Und dann sagt ihr einfach,
okay, ich unterstütze bis zu dieser
und dieser Version runter und
ähm...
Dann installiert...
Also was macht Tox nochmal? Also Tox
macht verschiedene Pythons. Ja, das
erzeugt dir zum Beispiel alle virtuell, also die
unterschiedlichen Virtual Amps in unterschiedlichen Versionen
und lässt dann da deine Tests
gegenlaufen und so und macht dann hinterher eine Zusammenfassung,
was alles funktioniert oder nicht funktioniert hat.
Woher nimmt denn Tox die Python-Version?
Ähm...
Das ist eine gute Frage.
Da...
Äh...
Ich weiß gar nicht,
ob es selber eine Möglichkeit
gibt.
Ob die auf der Maschine schon da sein müssen
oder ob es selber...
Docker oder...
Nee, nee, nicht Docker. Docker, das glaube ich
nicht, aber ich glaube...
Aber muss da sein?
Ich glaube, es kann die selber installieren
tatsächlich. Ich glaube, weil es nicht da sein muss, weil
ich glaube... Nee, ich
hab... Ich hab wahrscheinlich alte
Versionen nicht mehr, aber die Tox-Dinger testen
auch gegen alte Python-Versionen und
ähm... Das hat eigentlich immer funktioniert. Also
wahrscheinlich... Also, so mein...
Mein Guess wäre an der Stelle, ja,
Tox macht das irgendwie selber, aber
ich weiß es auch nicht genau. Okay, Bold Prediction.
Ja.
Es gibt auch Nox.
Gar nicht so sicher. Auch noch ganz interessant,
weil ich habe auch schon viel zu viel Zeit damit
verwendet, irgendwie
Tox-Inni so zu konfigurieren, wie ich das gerne hätte
und dann kann man da ja...
Und es dauert immer länger, als man denkt, dann funktioniert es doch nicht
und dann... Und bei Nox
kann man einfach Python-Code hinschreiben
und das finden viele auch angenehmer.
Ich habe es aber auch noch nicht, weil jetzt habe ich schon so viel...
Jetzt unterliege ich der
Sun-Cost-Fallacy und jetzt habe ich schon so viel Zeit
in Tox-Innis investiert. Jetzt gehe ich davon nicht mehr.
Weg.
Ich habe gerade mal nebenbei nachgeguckt
und es sieht so aus, als müsste man das vorher
installiert haben. Ach doch, okay.
Okay, also tatsächlich
PyEnv und dann alle Versionen, die du halt testen willst,
einmal draufhauen und dann Tox sagen,
wo die sind.
Ja, ja, ja.
Also ich finde so Backwards-Compatibility
Maintain auch fürchterlich, ne?
Ja, aber...
Ich nutze gerne sowas wie neue Sprachfeatures,
einfach so direkt.
Kann man ja auch so in Projekten,
die nicht andere Leute, auf die andere Leute
nicht dependen, kann man das ja gerne machen, aber ich meine,
wenn... Also viele können sich ja gar nicht so unbedingt
aussuchen, auf welche Python-Visienz sie sind und dann...
Ja, aber warum nicht? Das ist schon mal so ein
Infrastruktur-Problem, wo ich sagen würde, erst mal
dieses Infrastruktur-Problem lösen?
Naja, nee, zum Beispiel, wenn du jetzt die Kombination hast
aus Data Science und zum Beispiel Web,
dann gibt es halt diverse Geschichten,
so, weiß ich nicht, irgendwie PyTorch
oder Dinge in diesem Ökosystem,
die halt nicht
auf Python 3.11 laufen. Das kannst du
dann, geht halt noch nicht. Ja, aber genau, aber das ist halt
so ein Ding, ne? Harte, obere
Abhängigkeitsschranke. Warum laufen die nicht auf Python 3.11?
Ja, gut, weiß ich auch nicht so genau. Ja, aber das ist ja
genau der Punkt, weil die meistens haben ihre
Top, dann
gesetzt, oder viele Pakete in diesem Data Science
Umfeld, die gehen auch nicht für Python
größer 4, also größer 3,
also nicht für 4.
Ja. Warum auch immer man
das sagen möchte. Ich würde sagen,
warum nicht? Wenn Python 4, vielleicht läuft das ja noch.
Mal ausprobieren.
Ja, das ist nicht so einfach.
Ja, ich weiß nicht, haben wir denn
irgendwie noch irgendwie ein
größeres Thema bei diesem Paket?
Paketierungstools,
Projektmanagement?
Ich glaube vielleicht die Quintessenz, ne?
Dass es irgendwie nicht das beste Tool gibt.
Das wünschen sich irgendwie alle,
aber bis zur Zeit ist es leider noch nicht
aufgetaucht. Genau.
Ja, und es ist eben auch schwierig, das hast du ja auch
gerade beschrieben, dass man nicht von Python
aus dieses Tool herstellen kann.
Und es gibt immer mal wieder Ansätze, das zu lösen,
aber so wirklich das beste
Tool, was glaube ich alle
adoptieren werden, kann man es im Deutschen
sagen, was alle
benutzen werden, ist irgendwie noch nicht so wirklich
gefunden. Du hast es ja auch gerade gesagt, zum Beispiel
Rai kann ja theoretisch alles,
aber wenn es dann nicht wirklich dem
entspricht, auch diesem Workflow oder wie es
aufgebaut ist, wie man das gerne hätte und man
benutzt es dann nicht, dann fällt man eben
doch wieder auf eins der anderen Tools zurück. Und dadurch
entsteht das auch, dass so viele Leute so viele verschiedene
Tools benutzen.
Ja.
Euag zum Beispiel
oder sowas, wie heißt das? Habe ich noch nie gehört.
Das ist auch so eine Rust-Implementierung von
Python-Paketen
für VENVs und sowas, Format
Activate-Add und sowas.
Ja, aber dieses Bootstrapping-Problem
ist halt schon auch eines der
grundlegenden, dass man halt nicht
einfach irgendwie,
ja, dass man immer schon
irgendwie Python und Virtual
Envs und so, das irgendwie
können muss, um halt irgendwas, um sich
ein Tool zu installieren, das dann
Probleme löst. Und ja,
da bleibt wahrscheinlich nur der Ausweg irgendwie über
irgendwas zu gehen, was halt, wo
man halt ein Binary deployen kann, also Rust oder
Go oder so, aber
Ja.
Also ich würde gerne noch vielleicht ein, zwei Sachen zu diesem Packaging-Ding sagen.
Also mich interessiert das zum Beispiel noch, also wann würde man denn zum Beispiel
ein Package auf Pypi
publishen wollen?
Also es gibt ja da recht viele Pakete,
würde ich sagen. Ja, also ich denke,
das kommt total darauf an, also ob man das
irgendwie gerne einfach mal ausprobieren
will, habe ich auch schon häufiger mal mitbekommen, dass Leute
wirklich einfach mal
sich ein bisschen einlesen möchten in diese ganze Thematik
und wie funktioniert das überhaupt und dann so ein kleines
Beispielprojekt schreiben,
weil man muss ja nicht viel machen, man kann an sich
einfach einen Account erstellen und dann kann man
sein Paket hochladen und zugänglich
machen. Darum muss man, glaube ich, auch sehr aufpassen,
was man sich so installiert von Pypi.
Genau, oder
dass man, was auch
häufiger vorkommt, das ist jetzt dann, dass man
so einen internen Packaging
Index benutzen würde, wenn man
beispielsweise in einem großen Unternehmen
arbeitet und Code
zwischen verschiedenen
Gruppen oder Abteilungen teilen
möchte. So eine Core-Library quasi, so eine eigene.
Ja, genau, dass
man das dann hochlädt, sodass andere
das wieder installieren können.
Genau.
Gibt es, denke ich, verschiedene
Use Cases. Und
es gibt natürlich auch total viele tolle Open Source
Libraries, wie beispielsweise
4D.
Die man sich darüber
installieren kann, einfach weil
jemand sich mal dachte, boah, das
müsste man mal machen, das mache ich jetzt mal
und das total populär geworden ist.
Ich finde aber auch in dieser Hinsicht, wir hatten da ja gerade
schon mit Poetry drüber geredet, dass da so viele
offene Issues waren, teilweise,
dass man häufig auch vergisst,
dass da eine Person hinter sitzt, die das
eventuell noch in ihrer freien Zeit macht.
Und dass man das
auch ganz häufig
wertschätzender beurteilen muss,
als man es tut, wenn Dinge nicht funktionieren.
Das ist total krass. Also wie soll ich das denn
jemals schaffen? Also welche freie Zeit?
Fangen wir mal so.
Ja, das ist ja auch
ein sehr, sehr verbreitetes Problem,
dass Leute dann halt
irgendwie, also
dass dann Maintainer von so Projekten
verschwinden, liegt ja häufig daran,
dass sie das dann halt irgendwie hinkriegen.
Aber man kriegt das halt nur eine Zeit lang irgendwie hin
und irgendwann ist man halt einfach durch.
Und dann ist halt,
dann geht man halt irgendwie was mit Holz
machen oder so und das Projekt ist halt nicht mehr
Maintainer.
Ja, vor allem,
wenn der Ton dann nicht wertschätzend ist,
wenn Leute Ansprüche stellen und sagen,
jetzt sieh aber mal zu, dass du das machst
oder es funktioniert hier nicht und warum nicht und gib mir
bitte die Lösung.
Ja, stelle ich mir
auch schon ganz schön frustrierend vor, wenn man sowas hat.
Ja.
Ja gut, der Computer
und Internet und so, das ist eh
immer, oh je.
Ungefilterte Menschen aufeinander
loslassen.
Tja.
Die sich gegenseitig nicht sehen können.
Aber die Community ist auch, finde ich, sehr wertschätzend
und freundlich. Also wenn ich jetzt auf Python-Konferenzen
war, die Leute sind ja wirklich nett.
Also man muss dann irgendwie Sorge haben, Vortrag
zu halten und Fehler zu machen, weil
da sitzt niemand, der dich dann ausbuht
oder irgendwie sagt, boah, was hast denn du jetzt für ein Mist
fabriziert?
Also ich finde, die Leute in der Python-Community sind schon
sehr freundlich. Ja, vor Ort, die Leute, das
macht immer mehr Spaß als auch bei anderen
Sachen, die ich so kennengelernt habe im Check-in-Feld.
Ja, und man muss auch sagen, dass die Python-Community da halt
ein, ja,
so ein gutes Beispiel ist für, wie das
gut funktionieren kann. Das ist in
anderen Communities ist das nicht unbedingt so.
Also Python ist da doch besonders
angenehm, ehrlich gesagt.
Wir waren da natürlich nicht davor, irgendwie von irgendwelchen Randoms auf Reddit
angeschrien zu werden, aber...
Nee, gut, das kann natürlich auch mal passieren, aber
generell ist es, und vor allen Dingen ist es halt
auch besser als bei anderen.
Wir erinnern uns ja vielleicht selber an junge Jahre,
wo man vielleicht selber mal nicht immer den Ton
getroffen hat, den man eigentlich sich als Erwachsener hätte,
überlegt.
Ja, es passiert auch immer noch mit T und so.
Ja, genau.
Manchmal, ja.
Ja, mir passiert das nie.
Ich bin immer freundlich, immer höflich,
immer gut drauf.
Ja.
Ja, ansonsten, ich weiß nicht genau,
ob, ich hab sonst auch nicht...
Habt ihr noch ein Packaging-Thema?
Oder ein Management-
von-Environments-Thema, oder?
Nee, aber ansonsten, ich fand dieses
Automatic-Speech-Recognition-Thema auch noch total interessant.
Ich weiß nicht, ob du Lust hast,
drüber zu reden, oder...
Ich würde da super gerne drüber reden, aber ich darf leider nicht.
Ach so, ah, okay.
Also, das ist so ziemlich alles, was ich erzählen darf,
was ich schon gesagt habe.
Ja.
Leider, aber es ist ein super interessantes Thema,
das stimmt schon.
Okay. Ich überlege gerade, also für
Environment-Management oder Painting,
ich glaube, da haben wir so die meisten Tools so besprochen,
es gibt noch so ein paar mehr,
die wir jetzt nicht so gesprochen haben. Ja, aber ich glaube, ich weiß auch nicht, ob die wichtig sind
oder relevant. Wir können ja auch einfach
den
Vortrag verlinken oder auch den Blog-Post,
da ist dann auch nochmal das Ganze ein bisschen grafischer
dargestellt, das finde ich,
hilft natürlich auch für die Übersicht.
Es gibt eben auch ein paar Tools,
PyFlow zum Beispiel haben wir gar nicht angesprochen, das habe ich auch mit
aufgenommen, aber das ist so ein klassisches
Projekt, was mal angefangen wurde
und was nicht mehr maintained wird und
dementsprechend auch nicht unbedingt
empfehlenswert ist, das zu benutzen.
Ich habe es mal ausprobiert und
habe sofort ganz viele Fehler gehabt,
aber da sollte man auch immer drauf achten, was man
sich da für ein Projekt anschaut,
ob da wirklich regelmäßig Releases
rauskommen und die Issues auch abgearbeitet
werden. Ja, ich würde auch sagen, tatsächlich,
insgesamt bei Libraries so ein bisschen die Frage,
also manchmal tendiert man ja so ein bisschen
dazu, immer den neuesten heißen geilen Scheiß zu benutzen,
wenn er aber dann
halt im halben Jahr wieder weg ist, dann ist es halt blöd,
wenn man halt Projekte darauf direkt
aufgebaut hat und dann so diese ganzen
abgehangenen Sachen, die sind vielleicht nicht immer so
eine blöde Idee.
Ja, absolut.
Ja,
das ist halt immer so ein bisschen,
irgendwie, es ist
ein nicht unerhebliches
Feature, dass Dinge halt langweilig,
boring und alt
sind. Das kann auch sehr,
sehr gut sein.
Ja, alleine schon auch, weil dann
man in den Issues ja häufig
genau das Problem
findet, was man gerade hat und dass das schon
beantwortet wurde. Alleine sowas kann ja unheimlich
hilfreich sein, dass einfach
solche Probleme schon besprochen wurden und
schon zig Leute das Gleiche hatten.
Ja, genau. Und man kann
Chat-GPT fragen, weil
es war vor 2021 schon
irgendwie etwas, was man finden konnte.
Ja, ja.
Ja, das ist halt genau, also ich
weiß nicht, also das finde ich zum Beispiel bei Django immer toll.
Also ich meine auch, ich mag ja fast
API, ich mag das ja gerne.
Ich mag auch Pydentic, ich finde den Ansatz super.
Aber
das ist etwas, was halt bei Django echt
angenehmer ist, dass es da halt schon so viel Zeug gibt,
dass es halt eine 15 Jahre alte Geschichte gibt,
und ganz viel Content,
den man halt durchsuchen kann.
Und ja,
auch solche Dinge, auch da
ich mich persönlich,
also ich kriege immer, wenn
halt irgendwie so Venture Capital
ins Spiel kommt, dann denke ich mir immer so, oh nein.
Ja.
Und andere, also vor allen Dingen,
ich finde den Gegensatz halt interessant, weil die Leute,
die das dann bekommen, oder es ist halt immer so,
juhu, jetzt können wir endlich und so.
Und die Leute, die es benutzen, denken sich so, oh nein.
Ja gut, aber es ist halt auch
so ein Trade-off. Du hast natürlich einerseits Interessen
geleitete Entwicklung dann, und die ist halt nicht mehr
vielleicht so ganz neutral.
Ja, vor allen Dingen, weil Leute dann irgendwann ihr Geld wieder haben.
Ja, aber das ist ein
Problem, aber eine andere Frage ist halt auch,
du hast tatsächlich dann halt Zeit da und Geld
da Sachen zu bauen.
Ja, also brauchst du ein Geschäftsmodell, willst du eins haben,
willst du nichts. Und also, was immer ganz
schlecht ist, wenn die Leute auf einmal halt ihr Geschäftsmodell dann so
zufällig anpassen.
Genau, aber das finde ich eben bei solchen Projekten
dann halt auch oft irgendwie sehr nett, wenn die
dann, wenn es halt wirkliche Open-Source-Projekte
sind in der Community, wo nicht eine Firma dahinter
steht. Und wenn man halt eine Firma hat,
dann ist immer,
es ist tendenziell eher kurzlebiger, weil
vielleicht haben Firmen dann auch mal andere Prioritäten,
andere Interessen. Ja, eine kleine Anekdote am Rennen, ich weiß nicht,
ob ihr es mitbekommen habt und ob ihr euch damit
auskennt, aber es gibt Unity Game Engine.
Ja, ja, ja.
Das muss halt ganz viel Open-Source oder irgendwie
so Indie-Studios, die haben halt
auf Unity gesetzt und halt da ihre
Spiele entwickelt. Und die haben dann irgendwie gesagt,
so ja, neue Version jetzt übrigens, ach und
alle Projekte, also auch alle, die ihr irgendwann mal
angefangen habt, die sollen jetzt bitte pro Installation
so viel Geld teilen.
Das war natürlich
auf einmal geknallt.
Ich würde sagen, ist tot. Mal gucken.
Ja, es war sehr blöd
und die Leute müssen jetzt alle ihre Projekte umziehen
und so. Die sind jetzt wieder mal zurückgerudert,
wie es halt immer so ist, kommen wir so raus,
aber solche Sachen sind natürlich gefährlich,
wenn man halt dann von kommerziellen,
proprietären Anbietern irgendwie abhängig ist.
Ja. Das ist vielleicht nicht so.
Aber andererseits ist es aber halt auch eine Chance,
ne, aus diesem, ich mache das, als man
mein Hobby und da passiert immer...
Ja, natürlich, ja, ist alles irgendwie...
Also ich finde, ja, also Open Source ist halt
das Problem, ist halt meiner Meinung nach immer so
die Finanzierung.
Weil irgendwann kommen halt die meisten Leute,
also ich meine, es gibt vielleicht Leute, die so
viel Glück haben, dass sie mit so viel Geld
begegnet sind, dass sie nichts anderes machen müssen
oder die so genügsam sind,
dass sie halt den ganzen Tag verbringen
können mit wunderbaren Beiträgen an die
Community, aber oft ist man halt
leider gerade mit Familienhintergrund oder sowas
dazu gezwungen, irgendeiner Erwerb
Tätigkeit nachzugehen, die irgendwie
Einkommen erwirtschaftet und wenn das halt mit Open Source
nicht geht, ist es halt schwierig, ne.
Also ich versuche
auch immer tatsächlich, also bei den Konzernen, wo ich irgendwie
so da bin, irgendwen zu bewegen,
dass das so Geld zurückgibt,
also dass die zumindest dann so Spenden machen an Projekte
oder so, aber die hören dann immer so, ja, ja, total tolle
Ideen, würden wir auch total gerne machen, aber nein.
Passiert eher selten, leider.
Ja, denen ist das dann egal.
Ja, man müsste halt einen Grund dafür liefern
können und das ist, glaube ich, halt auch eins
der Dinge, wo man sich über Sachen überlegen
müsste, wie man das hängt. Also es gibt ja
diverse Ideen. Ah, ich finde übrigens genau
dieses Material Theme für MKDocs, du hattest das eben
erwähnt, der Autor davon,
der hat einen sehr schönen Weg gefunden, um damit
Geld zu erzielen. Der lebt ausschließlich davon
und der
lebt eigentlich quasi davon,
dass er Unternehmen einen Grund gibt,
ihm Geld dafür zu bezahlen und zwar
gibt es halt alle Features
sozusagen zuerst für eine Bezahlversion
und
die werden aber irgendwann dann halt
quasi auch in der, kommen halt in die
normale rein und alles ist Open Source,
aber wenn du halt irgendwie das ein bisschen
früher haben willst als andere, dann musst du halt zahlen.
Und das funktioniert wohl sehr, sehr gut.
Also, ja.
Aber ansonsten, ich würde sagen, das ist das zentrale
Problem. Also wie kann man Unternehmen klar machen,
ja, es wäre
nicht nur nett, wenn ihr das tun würdet, sondern ihr habt auch
einen Vorteil davon.
Also ich finde auch diese, also ich
muss halt auch darauf angewiesen sein, dass ich
jetzt mit Open Source, die ich benutze, dass ich die
für alles benutzen kann, also auch für Business, weil sonst kann ich
halt für meine Arbeit nicht verwenden.
Ja.
Was aber halt doof ist halt, wenn es halt nie,
wenn irgendjemand aber richtig viel Geld mitfindet, der halt nichts
zurückgibt, das ist halt irgendwie so der Deal dann gebrochen und
die Frage ist halt, ob man das lizenztechnisch irgendwie lösen kann.
Ich würde sagen, eher nicht.
AGPL war da natürlich so ein Versuch.
Ja, aber das ist halt eher kacke. Also bei mir führt es halt dazu, dass ich das gar nicht
verwenden kann, weil dann ich
sonst lizenzprobleme kriege,
die ich halt nicht haben darf. Deswegen kann ich die Software mit
AGPL nicht verwenden für Arbeitsprojekte, sondern nur
irgendwie in der Freizeit irgendwie und das bringt es halt
irgendwie nicht.
Ja, aber ja, schwierige.
Auch wieder ein schwieriger Ansatz.
Man kann ja jetzt zumindest bei
bestimmten Projekten, wenn man sie selbst als User
hilfreich findet, über
GitHub-Sponsors da was zurückgeben.
Das finde ich manchmal ganz schön. Und wenn es mal
nur ein paar Euro sind, die Wertschätzung
doch irgendwie mitzuteilen.
Ja, also das ist notwendig, aber
also schwierig, weil du halt davon abgelehnt hast,
dass das halt so dieses Spenden-Ding nicht
eigentlich, also meiner Meinung nach
müsste so der Staat so ein bisschen mit der
Gießkanne vielleicht sogar dahin gehen und was machen.
Gerade bei Umschuss.
Das hat ja noch viel zu wenig für sich entdeckt, weil also auch
Behörden und so sind ja abhängig von sowas und ich finde,
das wäre eigentlich so eine gute Sache, dass man sagt, okay,
es gibt jetzt so und so ein Budget, die halt dann
investieren müssen in so eine Infrastruktur.
Ja, aber das ist
halt auch wieder das, bist du das, oder
das ist halt das Problem, das zu erklären,
das ist halt so schwierig. Ja, dann hast du irgendwie so einen Prozess
und dann und so, ja.
Aber ja, vielleicht wäre tatsächlich
einfach das mit Steuergeld, aber ja.
Ich sehe nicht, dass das
passieren würde.
Ja.
Habt ihr einen Pick der Woche, Pick der
Folge?
Habe ich irgendwelche
Picks?
Ich muss nochmal nachdenken.
Hast du schon einen?
Was ist
tatsächlich mit Django Neapolitan?
Ah.
Kennt ihr das?
Nee, aber ich bin auch
wie gesagt Django noch nicht benutzt.
Genau, ja.
Guck mal rein.
Okay.
Ja, wenn man jetzt Django sonst nicht macht, dann bringt
einem das noch nicht so viel. Ja, würde ich auch sagen.
Also es ist Quatt, wenn man halt irgendwie
meistens hat man ja irgendwie so sein Quatt-Template
irgendwo liegen oder sowas und das ist halt
direkt mit drinnen.
Ja, die Idee ist sozusagen,
Class-Based Views ist halt
in Django problematisch, weil man
erbt von ganz vielen Dingen und die Dinge
erben wieder von ganz viel und oft hat man das Problem,
dass man nicht weiß, welche Methode muss man denn
jetzt überschreiben oder welche
darf man auf gar keinen Fall überschreiben und wann
passiert eigentlich was? Jochen ändert da an dieser Stelle seine Meinung auch.
Immer, ne, wie seine Popposen, ne, weil
ab und zu reden wir immer drüber.
Nein, okay,
nicht ganz. Aber, äh, also ich mag
Class-Based Views in Django immer noch sehr gerne.
Ja, also ich finde Class-Based
Views im Prinzip auch nicht schlecht, nur die sind schon
sehr kompliziert und quasi so
Vererbungs-Hierarchien sind halt auch etwas. Ja, aber dann machst du
halt einfach keine Vererbung, sondern erbst halt einfach nur von einem View
und dann hast du aber eine wunderschöne
Interface.
Also wenn du den Form-View nimmst, der erbt
halt von fünf unterschiedlichen Sachen und das
ist halt echt cool. Ja, dann halt kein Form-View.
Ja gut, okay, klar, aber
sozusagen die Class-Based Views sind halt so
komplizierte Vererbungs-Hierarchie und
man braucht dann halt sowas wie
Classy Class-Based Views. Irgendwie gibt es so eine schöne
Seite, wo man dann halt sehen kann.
Und
es ist halt vielleicht einfach ein bisschen
viel und deswegen sind viele auf
der, ne, ich verwende nur
Funktionen als Views-Seite. Oh ja, man hat dann
If-Request-Message-Post und sowas
und boah. Ja, hat
dann auch Nachteile, klar. Und
letztlich die Frage, gibt es was dazwischen? Und
äh, genau.
Es gab dann mal irgendwann von Tom Christie
Vanilla-Views, sozusagen,
um halt diese ausufernde
Vererbungs-Hierarchie in den Griff zu kriegen.
Aber das ist halt ein bisschen sehr wenig.
Und dann war halt sozusagen die Idee hinter Neapolitan
war halt, sagen wir mal, ja, es muss ein bisschen mehr
sein als Vanilla. Und also das ist quasi das,
wenn man das nicht kennt, also hier ist das immer,
wie heißt das ganz schrecklich, der Name? Fürst Pückler
Eis oder so.
Und ich glaube, die
internationale, der Name
dafür ist Neapolitan.
Und
deswegen, es war halt sozusagen die Idee, es ist
ein bisschen mehr als Vanilla, aber nicht sehr viel mehr.
Ja. Interessant.
Also ich kann immer empfehlen,
quasi Themenwechsel, anderer Pick,
was ich auch vorhin schon erwähnt habe,
Material für MK-Docs, finde ich
ein super cooles Package, wo man
wirklich einfach tolle Dokumentationen
bauen kann, was
doch meiner Erfahrung nach viel zu selten
gemacht wird. Mit was ist die, war das auch Markdown?
Genau.
Und dann kann man die
Dokumentation mit in seinem Repo haben.
Ich habe das so häufig schon mitgekriegt in kurzen Projekten.
Dass es überall verteilt war. Manchmal schon was
im Readme-File, dann gab es noch irgendwie eine Confluence-Seite.
Manches war in den Jira-Tickets
irgendwie dokumentiert.
Und das, finde ich, hat so
wenig Einstiegshürden, um
so eine schöne webbasierte
Oberfläche für seine Dokumentation
zu gestalten.
Mag ich auch. Würde ich auch
bevorzugen gegenüber Sphinx oder sowas. Finde ich schöner auch, ja.
Ja.
Ja, nee, ich finde das auch super.
Also ich verwende es vor allen Dingen
eben bei Fast-API-Geschichten,
weil es halt,
aber
ja, ja, nee, das ist schon toll.
Okay, was könnte ich denn?
Okay, ich picke mal was ganz anderes.
Du hast ja eben schon mit Rezepten so ein Buch
irgendwie da reingeguckt.
Ja, wundervoll, das
Ottolenghi-Flavor, das Gemüse-
Kochbuch.
Und zwar gibt's
ein schönes,
wenn man auf dem Mac ist,
gibt's eine sehr, sehr schöne App,
die nennt sich
Paprika Receipt Manager
und
genau, das verwende ich seit einiger Zeit
und finde das ganz, ganz toll.
Hast du das nicht schon mal gesagt?
Habe ich das schon mal gepickt? Oh nein!
Ich weiß nicht, ob du das gepickt hast, aber wir hatten es schon ein paar Mal.
Ah ja, okay, kann sein. Ich sage immer das Gleiche.
Ja, ich
ertappe mich auch dabei.
Aber es ist gut, dass ihr das noch mal gesagt habt,
weil ich hatte es nicht mehr auf dem Schirm.
Also ich finde, manchmal muss man einige schöne Sachen
noch mal ein paar Mal öfter sagen.
Man kann Dinge auch öfter sagen, ja, okay.
Wer weiß, wer immer bis zum Ende von jeder Folge bleibt
und wenn wir gerade so spannende Folgen haben,
wir manchmal haben wir,
spannende Folgen, dann
wer weiß, wie viele Leute am Ende noch übrig sind.
Genau.
Ja.
Dann ganz vielen herzlichen Dank an der Lena,
dass du da warst.
Danke, dass ihr mich angeladen habt.
Und ja, bleibt uns gewogen,
schaltet uns weiter rein, morgens, abends und so weiter
und wir wünschen euch eine wunderschöne gute Zeit
und bis demnächst.
Und hoffentlich bis in gar nicht mal allzu langer Zeit.
Ja, diesmal lassen wir uns nicht so viel Zeit.
Ja, wir haben auch so ein paar Sachen, Ideen.
Gut, bis dann, tschüss.