Transkript: Environment Management und Packaging

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 dazwischen gekommen, aber wir haben uns auch schon viele Leute geschaffen.

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 Anna-Lena heute sogar.

Hallo Annalena.

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 immer, 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 dazu kommt.

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 an etwas mitarbeitet, was auch wirklich beim User Verwendung findet.

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

In die man ganz viel findet, die ich auch ganz viel 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 Jochen auch.

Ich benutze

das noch.

Wir hauen es ja.

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 drüber nachdenkt, wahrscheinlich gar nicht so erstaunlich, weil das ein Problem ist, was so viele Leute betrifft.

Ja, und so.

Also ich würde auswählen, dass das so das Hauptproblem, wenn ich hatte, auch ein Neuling oder sowas, versuche Python beizubringen oder irgendwie denen 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 also nicht nur ein bisschen, sondern sogar ziemlich nervig.

Ja, ich bin da auch tatsächlich da auf deine Meinung sehr gespannt hinterher.

Auf deine 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 eingesagt.

Ja, würde sagen, das ist fast eine eigene Folge.

Das müssen wir, glaube ich, von 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, okay, na gut.

Wobei willst du erzählen?

Ich weiß nicht, einfach nur das, was mich in letzter Zeit so ein bisschen beschäftigte, wo ich dachte, okay, kann ich jetzt was zu sagen, weil ich es mich gerade betroffen hat, zum Beispiel, es gibt irgendwie ja, also seit letztem Mal Piedentic Version 2, sondern jetzt inzwischen sogar 2.4.

Wir haben ja auch die ganzen Europe Python jetzt noch nicht gemacht, also ne?

AI ist das richtig, ja.

Eine ganze Menge.

Und genau, da habe ich jetzt auch letztens ein Projekt umgestellt.

Ich wollte eigentlich nur updaten und dann hat das halt gemacht.

Cool, an Piedentic 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 ist jetzt auch schnell.

Alles das, was vorher langsam war, 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 PurePython macht, das alles zu validieren und in Rust geht das halt deutlich schneller.

Ja, aber genau, also achso, das hat man auch noch nicht erwähnt.

Es gibt jetzt eine Firma hinter Pydentic und die hat auch irgendwie, glaube ich, von Sequoia oder so, ordentlich Venture Craft Hill bekommen.

Und die Entwicklung.

Das habt ihr, glaube ich, erwähnt in der letzten Epic.

Hatten wir schon erwähnt.

Achso, gut.

Habt ihr schon erwähnt, ja.

Okay, genau.

Aber die Entwicklung geht da jetzt auch deutlich schneller und 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.

Und das lag dann letztlich daran, ich meine, das ist halt auch so ein Ding.

Das kann dann passieren, wenn man Dinge ändert.

Da halt halt irgendwie früher war es halt so, dass wenn man bei so einem Feld gesagt hat, Typing any, dann war das default-mäßig none.

Und das ist es jetzt nicht mehr.

Jetzt ist es halt, kriegt man einen Fehler und das sagt halt irgendwie, du hast dann einen Wert nicht gesetzt.

Und dann runter kommen aber die anderen Variablen und dann hatte ich das irgendwie falsch einsortiert und bin dann irgendwie falsch abgebogen.

Und dann musste ich halt irgendwie, weil das 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 anderen.

Ja, das war schon, dachte ich so, 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 brauchen, bis ich alle Sachen, wo ich Fire-Dic verwende, umgezogen habe.

Benutzt das auch in Django?

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 ein Django Rest-Framework geht.

Genau, ich wollte gerade sagen, ich kann Django Rest Frame.

Doch, also für so Rest Upies nehme ich nochmal so Django Rest-Framework, aber manchmal kommen Daten ja auch von irgendwo anders und dann nehme ich schon ein paar Dentiker.

Da gab es ja auch ein paar News zu, ne?

Ich glaube, Rest-Framework wird irgendwann deprecated und nach Django reinwandern, irgendwie jetzt mit 5 sogar schon.

Ja, das weiß ich noch nicht.

Also die Kerngeschichten wandern wandern in Django selber rein.

Ja, also quasi das Encoding-Geschichten, also es gibt größere Teile, die in Django jetzt selber sind und dann könnte man halt sowas wie die 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 ist es aber natürlich keine Sache, ne?

Also man bräuchte das wahrscheinlich dann gar nicht mehr, wenn man das einzige.

Das ist nicht mehr großartig, genau.

Das ist halt.

Insbesondere wenn man dann diese Patentic Validation macht oder sowas, ja.

Ja, ja, ja, also das ist auch noch interessant.

Also es gibt ja dieses Django Ninja oder so.

Ja, das ist komisch.

Ja?

Ich bin schon.

Okay.

Ja, das habe ich auch noch nicht verwendet, also müsste ich mal vielleicht.

Ja, ansonsten, was habe ich denn noch so?

Ach ja, die LLM-Geschichte, das war ja die vorletzte Episode.

Wir haben uns also quasi gerade mit beschäftigt.

Die eskaliert auch immer noch so munter vor sich hin und wird immer, da gibt es auch jede Menge Neuigkeiten.

Kann man auch nicht alles abdecken, ist einfach so viel, was da passiert, aber eine wichtige neue 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 tatsächlich irgendwie mit Lama 2, was halt jetzt richtig offiziell irgendwie dafür gedacht ist, dass man damit Dingen machen kann, das kann man halt super fein tunen.

Gerade die kleineren Modelle kann man super fein tunen auf irgendwelche Probleme.

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

Daher, ja, habe ich mir auch schon gedacht und gedacht, nehmen wir das nicht, aber ja.

Ich würde gern.

Naja.

Weißt du, was ich rausgefunden habe für meinen LLMs noch wunderbar benutzen kann, wo ich sehr überrascht war?

Nee, Musiktipps.

Musiktipps?

Ja, 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 hast du, hey, ich höre das und das, gerne hast du ein paar gute Tipps.

Und was rauskommt.

Also ich fand die Tipps hervorragend.

Ich habe so ein paar Sachen gefunden, die ich noch nicht kannte und so.

Cool.

Habe ich noch nicht verwendet für, aber klingt gut.

Muss man probieren.

Ich glaube, dazu gab es tatsächlich sogar einen Talk, genau mit der Topic bei Europython.

Ach recht.

LLMs for Music Recommendation.

Ach, witzig.

Toll.

Ich dachte gerade, du hättest den gehört.

Nein, den habe ich tatsächlich nicht gesehen, sonst hätte ich den auch jetzt empfohlen, aber den habe ich tatsächlich verpasst.

Wir sind jetzt alle auf YouTube seit einer Woche, glaube ich.

Ah, gut.

Okay, also auch noch in die Shownotes, dann können wir nochmal die Europython Talks verlinken.

Ja.

Genau, ansonsten, ja, Postgres 16 ist raus.

Ist jetzt zwar nicht so wirklich was mit Python zu tun, aber vielleicht, die meisten Leute oder dürften ja auch irgendwie eine Datenbank verwenden und viele verwenden wahrscheinlich Postgres und da habe ich jetzt auch meine ganzen Geschichten geupdatet und das ging auch problemlos.

Also von 15 nach 16, wenn da PG-Upgrade einfach drüber laufen lässt, es hat einfach immer so funktioniert, auch mit 14.

Also es war ein sehr problemloses Update für mich.

Und ja, hat auch eine Menge nette Sachen drin.

Ja, ansonsten, weiß nicht, 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 gesagt, das sprengt absolut den Rahmen.

Wir haben da auch einen Channel zu bei der Arbeit 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

ja mal.

Ja, ist immer die irgendwie 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 sicher, als das wird bleiben oder es nicht so nicht nur Hype irgendwie erwiesen haben, sich das dann nochmal anzugucken.

Ich weiß es nicht.

Schwierig.

Schwierig.

Ja.

Ja, gut, aber ansonsten.

Ja, ich würde.

Meine News sind alle gerade nicht so technischer natürlich, deswegen skippen wir die für heute einfach mal.

Okay.

Gut, gut, gut.

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.

Wollt ihr auch über das Python Virtual Management reden?

Das hatte ich auch als Kategorie noch mit aufgebracht.

Also Finte gehört auch dazu und das überschneid sich ja teilweise auch, weil auch Pyen für Virtual Environments macht und so, wenn man will.

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 Windows-Maschinen, sondern halt nur auf POSIX.

Es gibt aber so einen 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 Minikonder oder sowas, was ja bei der POSIX ganz gut funktioniert.

Ich 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ß, vielleicht, ich fange ja auch an mit PyEnf.

Also ich würde tatsächlich PyEnv installieren und dann mit PyEnv die PyS-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 nochmal sagen, was die Tools überhaupt machen.

So zur Vollständigkeit.

Sonst sind sie alle wieder direkt aufgestellt.

Oh, ja, ja.

Das Feedback habe ich schon einmal bekommen und das war aber ganz schön schwierig.

Ja, genau.

Also ich hatte am Anfang überlegt, als ich mich mit der Thematik beschäftigt habe, ob es Kategorien gibt, weil bei Python gibt es eben unheimlich viele Tools, die alle verschiedene Dinge können und Mati 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 eins der wenigen Tools, das das wirklich macht.

Viele, die das, also zum Beispiel Rai 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 erstmal 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 Version hin und her wechseln.

Ja, ja, also ich brauche es auch genau, also lokal, wenn ich irgendwie auf einer Entwicklungsmaschine unterwegs bin, da ist es 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 einen 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 Python macht auch noch so Sachen wie, man kann halt Minikonder, also es gibt ja auch so ganz unterschiedliche Python-Ökosysteme, also je nachdem, also wenn man in einem Data Science-Umfeld unterwegs ist, da ist halt eher so Konda das Tool, was man benutzt, um halt Abwägigkeiten zu installieren.

Und vielleicht will man halt dann eher so die Minikonder-Python-Version haben, was wieder was anderes ist als diese komplette Annaconda-Distribution, das habe ich auch schon ganz oft gesehen, dass Leute mit der anfangen und das dann halt für Sachen verwenden, wo ich denke, oh nein, da brauchst du eigentlich Minikonder und irgendwie ein Virtual Elf oder so, kannst du das komplette Ding ist halt eher.

Das ist oft

halt so ein Einstiegspunkt, weil das halt oft in der Data Science-Welt irgendwie so empfohlen wird als Entry Point.

Kann man mit Py einfach die ganzen Dialekte installieren?

Also sowas wie R-Python oder H-Python oder sowas?

Das weiß ich nicht so.

Also PyPyPy geht, ich gebe Logal 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 Symbolie.

Wird es nicht zu tief 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, tiefe einzusteigen, damit man zumindest mal einmal versteht, was der Unterschied zwischen Conda, Anaconda, Minikonda und so weiter ist.

Aber es ist schon wirklich riesengroßes.

Also vielleicht sagen wir das nochmal kurz, wenn wir jetzt schon jetzt bei Conda sind, dann bitte.

Vielleicht haben wir das einmal so kurz so als Elevator.

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 Ents verwenden den gleichen Interpreter, die halt mit dem gleichen Interpreter erzeugt wurden.

Oh nein!

Eine virtuelle 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 sich 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 in dem anderen Django 4, dann die wären sozusagen im gleich

en, ja auf dem gleichen Isolationslevel, dann würde man ja quasi die Abhängigkeiten vom einen kaputt machen, wenn man am 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 die leichtgewichtigste Art von Isolation, weil der Interpreter ist, wenn man jetzt zwei unterschiedliche Projekte mit zwei unterschiedlichen Virtual Ents hat, ist man halt noch gleich.

Aber die Pakete, die installiert sind, sind total.

Ja, ist ja auch bildet, ne?

Python-mvenv und dann

Sachen machen.

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 oder, 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, 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 Lib C hat oder sonst irgendwas oder alte Bibliotheken, die man nicht verwenden möchte.

Und man kommt halt, man hat halt gar nicht Berechtigungen, 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 Condor da einfach das Ding, womit man Sachen hinkriegt, die dann mit Pip nicht gehen.

Ja, jetzt sind wir schon direkt drin.

Also es gibt ja Pip, was macht Pip?

Pakete von Pipe AI installieren?

Genau, vom Cheese Shop.

Und ja.

Und Conda installiert jetzt auch irgendwie externe Binaries noch und die gar nicht Python sind.

Und da gibt es noch ein anderes Tool für.

Das häufig man häufiger nutzt, oder?

Noch eine Isolationsschicht weiter oder noch weiter insoliert.

Also ein Tool, also ich würde sagen, das nächste Tool in der Reihe wäre halt Docker.

Oder Pip X?

Pip X macht das gleich wie Pip, nur dass es halt für das, was du installierst, ein eigenes Virtual Enf erzeugt trägt.

Ja, oder es macht aber auch externe Sachen halt in Sachen, die einigen und teilweise Binaries, die du halt direkt da unterziehen kannst.

Also das wusste ich gar nicht.

Ich habe gerade noch überlegt, vielleicht noch einmal zum Anaconda und Minikonda.

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 Minikonder 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, also ich denke, also wenn man jetzt halt noch härter isolieren will als mit Conda, dann wäre halt Docker das Ding, was man noch verwenden kann, was halt viele benutzen.

Ja.

Ja, ist halt langsamer.

Aber ich finde Conda so ein bisschen intuitiv, weil Conda relativ hart immer den Pfad direkt angreift, zumindest auf ein System und dann muss man immer so ein bisschen aufpassen.

Ich glaube, also

muss man bei all diesen Dings.

Ja, generell, der Pfad ist immer so das, wofür viele anfängen, 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 läufen sollte und sowas.

Das ist so ein bisschen hampel.

Ich habe auch mit Conda 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 Konda, vor allem wenn sie jetzt nicht aus dem Computer Science-Bereich kommen, doch recht hilfreich finden.

Ja, ich meine, manchmal muss man bei Pip halt 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, braucht man 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 halt 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 da kann nicht, ja.

Und das ist natürlich so ein bisschen eine doofe Situation, weil muss man lange erklären und so.

Ja, häufig finde ich es auch hilfreich.

Also ich arbeite ja immer in 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 man 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 den Editor einigen muss.

Also es ist ganz gut, wenn die Sachen editor agnostisch funktionieren.

Ja, das stimmt.

Aber manchmal kann es auch ganz hilfreich sein.

Also ich finde, es kommt, also es kommt wirklich sehr auf die Kunden.

Solange alle Leute das so machen, wie ich das richtig halte, ist das natürlich so.

Ja.

Genau, wo waren wir denn überhaupt?

Python ist es nicht.

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?

Wenn ich halt die Python-Version mache.

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

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.

Hätte ich gedacht so, nee, das kann nicht sein.

Doch, ist aber so.

Also das ist tatsächlich die von mir momentan präferierte Art, Python auf irgendeinem Produktivsystem zu installieren, ist halt selber zu kompilieren und.

Source-Code und bauen, okay.

Und auch nicht.

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

Da kann man das Tool mal ausprobieren und dann mal gucken, was die neue Python-Version so besonders macht oder mitbringt.

Beta-Versionen oder Release-Kandidates oder so, das ist immer sehr nett dafür.

Genau.

Ich bin cool finde, dass ich das selber kompiniere im Produktivsystem.

Warum nicht PyEnt im Produktivsystem?

Naja, deswegen, weil ich, also das, 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, also ist es mir doch lieber, dass halt, weil ich hätte sowieso gerne immer die gleichen Python-Versionen für alle.

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 was drin hängt und jetzt musst du halt eine alte Version nehmen.

Ja, passiert bei meinen Sachen nie.

Okay, ja, okay.

Also ich habe so ein paar Kunde geht, dass so.

Ja, ja klar, klar.

Ja, also der Vorteil von PyEnv ist halt, ich kann halt einfach auch die Version einfach dann installieren.

Und wenn in meiner Production-Pipeline Pyenf 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 nutzen möchte.

Ja, siehst

du, komm 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.

Dass man dann nicht mehr diskutieren muss.

Da gibt es ja gerade tolle Versuche, das zu lösen irgendwie, ne?

Also man wird 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 Rai erwähnt, dass es das Tool von Armin Runacher, was auch in Rust geschrieben ist, der jetzt so erst wie Rust aber macht, dass so seine Opinion ist, wie man so Projekte einneu baut.

Ehrlicherweise, also ich bin da so ein bisschen anderer Meinung, wie man das richtig machen würde.

Also ich mache es anders, mein Test ist anders.

Aber das ist eigentlich ja sowas, 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 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 noch 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 erstellen wollte, Venve benutzt oder Virtual Env, um das schnell machen zu können.

Also ich bin das Versuch dann immer noch Virtual Envrapper, weil das halt dann irgendwie nur so drei oder vier.

Ja, da gibt es ja noch ein paar interessante Shell-Aliasse, die man dann sozusagen.

Ja, also ehrlicherweise auf Windows, ich muss ja, wenn ich Windows benutze, ist das ja mal Quatsch, da gab es irgendwie Virtual-Ent Wapper Power-Shell, das irgendwie fürchterlich war und ich habe es mir einfach selber geschrieben, was eigentlich nur ein Rapper um Benfist.

Du willst halt sowas haben wie MK Virtual Env oder RM Virtual Env oder LS Virtual Env, um halt deine VirtualMs anzuzeigen, die du hast und die du halt einfach dann aktivieren kannst mit sowas wie Work-On.

Also ich finde das Schönste an Virtual Wrapper ist Work-On.

Du gehst halt einfach in dein Projekt und gibst ein Work-On in der Shell und die Enf 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 Ents Pi-Env, weil das könnte man ja auch machen.

Also ich hab's, ja, nein, also ich benutze es nicht mehr.

Ich habe es noch nie benutzt dafür.

Okay, ich hab's mal dafür benutzt und mache es aber nicht mehr, weil das ist damit sich das erledigt, als ich dann von ZSH auf Fisch umgestellt habe, die Shell und jetzt zwar verwende ich halt zum Verwalten der Virtual Ads, Virtual Fisch, was ich auch noch empfehlen kann, wenn man die Fisch Shell.

Ja, genau, nee, verwende ich auch nicht mehr.

Ja, genau, also ich benutze tatsächlich für Erstellen von VirtualEms meistens Poetry.

Da würde gleich ein großer Aufschrei kommen, weil da gibt es große Diskussionen um die es tut.

Und ich benutze das tatsächlich immer noch und ja, weil das in den Projekten ich eh eine Pi-Protect-Hummel habe, wo die die Dependencies drin definiert sind, dann mit Poetry relativ easy geht.

Und wenn ich mal selber eine eigene Venv kurz brauche, dann einfach mit dem Virtual Enfrapper, einfach MK Virtual Env 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 einen Pi-Projector-Tommel-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 Venf.

Ja, das ist über die Pipe-Prote-Tool, müssen wir, glaube ich, später auch nochmal sprechen, weil es da ja auch verschiedene Ideen gibt, wie man das strukturiert.

Und da bin ich auch mit so Sachen, die Pootri zum Beispiel macht, nicht so einverstanden.

Und da gibt es ja so ein paar Paps, 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 PipE.

Das ist auch schon ein ziemlich altes Tool, was einem dann auch noch erlaubt, also das sagt der Name ja auch schon, dass es Pip und VirtualEnv zusammenführt und das Ganze nochmal ein bisschen mehr abstrahiert, also noch mehr Funktionalitäten hat und man darüber auch Packages installieren kann.

Pip Envölker

relativ komische Dinge.

Weiß ich nicht.

Also früher war, also es gab eine Zeit lang, war halt da mal so ein bisschen das Problem, was man gehört hat, dass oder dass das nicht richtig mit Hand wäre oder so.

Aber ich glaube, das ist nicht mehr so.

Das ist inzwischen, weil es halt auch eins von den Projekten von, na, wie heißt er noch?

Kennis Rights.

Ja.

Ursprünglich, aber der hat damit, glaube ich, nichts mehr zu tun.

Also ich glaube, das war mit so einer der Gründer, wo ich gesagt habe, aber ja, wenn das jetzt in anderen Händen liegt, nochmal angucken.

Ja, okay, hat auch noch so eine Schule.

Ich glaube, es war ganz viel in diesem Bereich, da kommt es aber auch drauf an, was man gewohnt ist, was die anderen benutzen.

Und 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 Python Enhancement Proposal gab zu PyProject.tommelfiles, dass man die benutzt.

Und die haben eben auch so einen eigenen Weg, das zu machen.

Also wenn man Pipn benutzt, hat man plötzlich einen Pip-File noch da und auch ein Pip-File.log.

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 dich 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 Rai, Hatch, wie auch immer.

Was haltet ihr von PDM?

Oder was hältst du von PDM?

Ich habe es jetzt noch nie in einem Projekt benutzt, also einem Kundenprojekt.

Ich habe es mal selbst ausprobiert.

Darum kann ich da nicht so viel zu sagen.

Ich habe es natürlich mir angeschaut für den Talk und fand es jetzt ganz cool.

Aber ich kenne auch Leute, die darauf schwören, also die das richtig gut finden.

Man muss zu PDM aber sagen, ich hatte es ja vorhin kurz erwähnt, dass die meisten Tools Virtual Environments benutzen.

Und PDM ist eines 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.

Und ich glaube, am Anfang gab es darum auch sehr viel Interesse an dem Tool, dadurch, dass es halt diesen anderen Weg benutzt.

Ich bin mir nicht sicher, was jetzt passiert, dadurch, dass es abgelehnt wurde, ob das irgendeinen Unterschied macht.

Diese Local Environments.

Da gab es auch so ein paar Teilen.

Da weißt du mehr als ich kann gut sein.

Ja, okay, ich kann das gar nicht.

Ja, also ein Ding, was mir nicht so klar war, als ich also früher und jetzt, dass das viele Dinge gibt, die sehr unterschiedlich.

Also, ich meine, es ist natürlich schön, wenn man ein Tool hat, das irgendwie alles macht, aber und das war auch einer der Gründe, warum ich irgendwann mal auch eigentlich recht begeistert war von Poetry.

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, naha, so richtig, so leider sind die Sachen doch sehr unterschied, also so unterschiedlich, dass man sich dann doch dafür interessieren muss, dass diese Abstraktion halt anfängt zu leaken und dann wird es halt hässlich.

Für mich jedenfalls.

Also ich finde Poetry super, weil es halt drei Sachen für mich macht.

Und das ist halt Dependencies für ein Projekt dazufügen, Dependencies für ein Projekt installieren, Dependencies für ein Projekt updaten.

Und das ist so das Hauptding, für das benutze und es ist trotzdem total nervig und ich gehe 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 Poetryfilme nehmen würde.

Ich habe gerade irgendwie Flitter Hatch irgendwie besser dafür geeignet, aber da kommen wir vielleicht auch noch drauf, wenn wir Packaging besprechen.

Ja, weil ich würde sagen, solange man nur Projekte hat, wo man halt andere Abhängigkeiten reinzieht und die man dann halt irgendwie irgendwo installiert oder irgendwo hindeployt und so, da funktioniert das ganz gut.

Aber sobald man halt eigene Libraries hat, wo man irgendwie Pakete erzeugen möchte, dann beißt einen das so ein bisschen, dass da die Anforderungen einfach völlig anders sind als und ja, also da finde ich halt zum Beispiel, also da fand ich halt Poetry, macht da Dinge, äh, da hat mich sozusagen kalt erwischt, dass die halt zwei sehr unterschiedliche Use Cases sind.

Und ich dachte, ich könnte das halt für beides gleich verwenden und ein paar

Schatzbox halt nicht gemacht.

Und dann will man halt irgendwie den Pfad für Poetry homesetzen und dann installiert es aber trotzdem irgendwo anders, andere Dinge hin und sowas, dass es halt einfach total nervig ist und.

Das Schlimmste war, dass, also bei meinem Anwendungsfall, das habe ich wirklich nicht gewusst, und das hat halt Sachen draußen kaputt gemacht, ist halt das Poetry per Default, was ja vielleicht okay ist für Applikationen, die man irgendwo hin deployt, 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 war ich erst anderer Meinung und das macht im Data Science-Umfeld, macht das unheimlich viele und unheimlich viele Pakete, die halt oberschranken drin haben.

Und es gab diesen sehr länglichen Blogpost dazu, den du mir geschickt hast, den wir ja auch nochmal verlinken können, der mich auch überzeugt hat zu sagen, das ist wahrscheinlich eine ziemlich doofe Idee, überhaupt so eine obere Schranke zu haben.

Interessant, das ist 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 13 gehen und willst aber 31 nehmen, dann musst du es halt irgendwie umbauen oder sowas.

Das ist halt schon ätzend.

Ja, eigentlich gar nicht so sehr dabei, sondern eher so bei irgendwelchen Third-Party-Geschichten.

Also man hat halt irgendwie eine Crypto-Library oder so, die man halt als Abhängigkeit verwendet, wenn man irgendwas, wenn man die für irgendwas braucht.

Und dann sozusagen hat man eine implizite obere Schranke, auf diese, auf eine Version von diesem Paket.

Und jemand installiert jetzt eine Library, die man selber irgendwie gebaut hat, und hat aber noch eine andere.

Und jetzt sagt die eine, irgendwie, ich brauche aber Abversion so und so, weil die hat halt irgendwie so eine 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 kannst 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, also das ist so ein bisschen.

Und das ist halt genau.

Und wenn dann Leute sagen, so, ähm, deine Library ist, die macht irgendwie hier bei mir Dinge kaputt, dann das ist halt nicht so schön.

Genau, und das also im Data Science auf der hatte ich das recht häufig bei irgendwie Machine Learning-Paketen, dass du halt tatsächlich hingehen musstest, müsstest in den Paketen die Requirements so anpassen, dass es halt irgendwie funktioniert und gucken, ob es angeht, was man halt dann auch nicht so genau weiß.

Aber das, ja.

Habt ihr das mal mit anderen Tools ausprobiert, ob das Problem dann auch besteht?

Ja, passiert auch mit dem damit.

Also apropos Tools, Jochen, du mirst 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 habe, also wie ich halt auch sowas wie Blogfiles habe, bei meiner Library habe ich ja keinen Log-File.

Aber bei einer Applikation hätte ich natürlich schon, wir haben einen Log-File, sodass halt alle Entwickler irgendwie das halt weiß.

Was nochmal ein Log-File ist, wenn wir auch noch ein Low-Level hängen wollen.

Also ein Log-File ist normalerweise pinnt halt die Dependencies und insbesondere den Subdependency-Graphen halt mit für deine Dependencies, dass halt klar ist, dass du die Versionen und die Abhängigkeiten dieser Pakete, die du da benutzt, auch gepinnt sind und meistens hashest sie noch.

Das heißt, du kannst halt sehen, ob irgendwelche Änderungen da sind.

Also aus der Security-Perspektive gar nicht so interessant.

Ja, ob das, was man runtergeladen hat, auch tatsächlich das, was man haben wollte.

Und ja.

Also es führt halt dazu, dass, wenn zwei Leute sozusagen das Virtual Env mit allen Environments bauen, finden sie genau das Gleiche und haben nicht unterschiedliche Versionen von der Bildung.

Genau, also das ist das Hauptproblem auch, also ein klassisches Ja Requirements TXT.

Genau, da wäre es 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 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 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 Blockfiles halt und deswegen, also diese Blockfiles sollten eigentlich meiner Meinung nach auf jeden Fall Teil von so einem Projekt mit sein.

In welcher Form auch immer.

Von der 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 Anwendungen, die ich deploy, nehme ich halt Pip-Tools und für den, ich habe 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, aber 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 hattet, mit diesem Unterschied zwischen abstrakten und konkreten Abhängigkeiten.

Das kann man vielleicht auch nochmal ganz gut in Verbindung mit dem PyProject TOML-File erklären, weil wenn man ein Paket baut, hat man eben PyProject TOML-File, wo die ganzen 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 Pi-Project.

Also die ganze Konfiguration halt, ne?

Löst halt diese Placeur an Konfigurationsfiles ab, die dann irgendwo im Projektroute rumfliegen müssen, ja.

Ja, und die Dependencies, die man da reinschreibt, sind aber möglichst 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 sein Repository oder Package, sodass alle genau das AM gleiche Setup reproduzieren können.

Setup ist, glaube ich, ein gutes Stichwort.

Ich glaube, früher hat Python das halt mit Setup-Pi gemacht und Setup-Tools.

Dann war das halt in Python und halt nicht in dieser deklarativen Tummel-System.

Ja, die Geschichte davon ist auch.

Also da gibt es ja dann noch sehr viel mehr.

Es gibt auch noch Disk-Tutils und ach, weiß 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, das sich irgendwann mal irgendwie hingeschrieben haben, halt kopiert und das war halt so ein Problem.

Deswegen muss 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 Semester.

Es ist auch überraschend, finde ich, also dass ich habe gerade mal das PEP geöffnet von, das ist 518, wo es darum geht, dass PyProject.tommel 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 Py-Projekt.

Tommel-Datei hat, in der man im Tommel-Format eben definiert, wie das Paket aussieht und welche Abhängigkeiten es hat.

Also was ich so ein bisschen anstrengend finde, ist, dass es da keine Referenzen gibt in diesen Tommel-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 Pi-Projekt Hommel 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 Pi Project Homel zu nehmen.

Also Flake oder so.

Flag 8 ist halt so ein Kandidat für, nee,

ja, genau.

Aber das geht auch.

Und dann muss man halt ein extra Paket installieren, dann geht das.

Das gibt halt so ein Fork davon quasi.

PiTest oder so ist halt auch sehr schön.

Darüber einshaper, MyPy, Rough und deine ganzen Tool-Teil, ne?

Linting und sowas.

Die Skripts, die Skripts finde ich auch sehr interessant, weil da gibt es ja auch verschiedene Sachen, das noch zu lösen, welche Skripte man irgendwie einhängen will.

Ja, das finde ich auch ganz schön.

Ich hatte das auch jetzt gerade im Kundenprojekt wieder, dass jemand ein Mac-File 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.tommel-File definieren kann.

Also wenn man zum Beispiel immer Python-MUnit-Test Discover Test schreibt, dass man das einfach abkürzen kann, indem man in der PyProject.Tommel 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 deinem 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 mal meinen eigenen Wrapper geschrieben.

Bei mir heißt es dann CC, weil ich habe meinen C-Compiler gelinkt und dann einfach CC Up, CC Start, CC Test, Call Command.

Aber man muss dafür das Paket quasi installieren im aktuellen Environment, ne?

Genau.

Ja, aber das ist halt sowas, wenn ich jetzt in einem Projekt bin, das halt, also sagen wir mal, ich habe ein Django-Projekt oder so, dann installiere ich das ja gar nicht als Paket oft.

Dann ist halt wieder so diese Unterscheidung.

Bei dem, wenn ich ein Paket entwickle, okay, dann habe ich das normalerweise auch immer in einer editierbaren Version installiert im aktuellen Environment, aber und das ist wieder diese Unterscheidung zwischen Library und.

Install-E oder sowas, ne?

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 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 Accept 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 bei Zeugnum 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 noch erklären muss, nee, du musst erst das Paket installieren und dann so, welches Paket?

Ja, das, okay.

Und dann das ist halt immer nochmal eine Hürde.

Ja.

Ja, ich weiß es nicht.

Ich habe da noch 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 Hatch oder Poetry, PDM, Rai, dass die für 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, Hedge, Run und dann Python, main.py oder was auch immer.

Und dann lässt Hedge dieses Skript innerhalb eines Virtual Environments laufen, wo alle diese Dependencies, 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.

Ja, ja, dann, also Poetry zum Beispiel, jetzt kann man halt auch dann konfigurieren, dass halt alle Venfs in einem bestimmten Ordner liegen, wenn man das gerne hätte.

Oder dass sie halt im Projekt liegen.

Also das gibt ja 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 VEMs vergleichen will oder ob man das halt in Pod macht, wo man das vielleicht direkt ins Projekt legt.

Oder irgendwo nach Opt oder ich weiß nicht.

Häufig einfach den Default benutzt.

Also ich mache, also ist unterschiedlich.

Für Entwicklungen lege ich die ganzen Virtual Enfs 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 Enf in einem Projekt und dann das dann halt nicht backup.

Was auch geht, aber ist halt komplizierter und wenn ich mich dann an diese Regel selber mal nicht halte, dann wird halt ein Virtual Enf gebackuppt, was halt doof ist.

Ja, also ich habe aber tatsächlich schon gesehen, dass tatsächlich sogar die VAMs Teil der Version Control sind.

Ja, das ist natürlich.

Nee, also das wollte ich gar nicht.

Ich kann das auch nicht machen, aber das habe ich schon gefunden, weil die Leute halt irgendwie die brauchen, reproduzierbar auch irgendwie auf ihren System, dann halt tatsächlich einfach die Venf auschecken.

Und dann haben sie die schon, ohne dass sie diesen ganzen Hassel 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.

Wenn man dann halt jetzt nicht, also den Python nur gelingt hat, sondern das halt als harter hingeschrieben hat, dann könnte das sogar funktionieren.

Also, ich habe Zweifel.

Ja, gut, aber das ist halt wieder genauso 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-Anwendung, die alle nicht so richtig gut funktionieren und so.

Ja.

Alle Probleme haben an irgendwelchen Edge Cases.

Also es gibt, das ist tatsächlich halt das Beispiel Rust ist da, glaube ich, echt ein gutes.

Also weil du machst Rust ab und hast da einen Kargo und sowas und das ist.

Ja, aber man kann halt, man kann, das wird ja dann auch oft vorgeschlagen, also, warum machen wir es nicht einfach, wie wir 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 irgendwie machen.

Zum Beispiel den ZR-PY-Support einstellen.

Das haben auch Leute schon eingedacht oder probiert und dann bei den Diskussionen könnte man raus, nee, es ist unmöglich, es geht nicht.

Kann man nicht machen.

Also wer Pistel 4 dann.

Selbe Problem, ja, ja.

Das will auch keiner mehr machen.

Das will auch keiner machen.

Das ist ja so ein harten, solche harten Kompetitivitä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 Enf 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 oder Aua, da gibt es auch noch dieses Dings, was ich auch noch mit entfernen, sondern dann enthalte 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 Laufen notwendig ist.

Also zwei Sachen, aber ja.

Ich habe gerade noch daran gedacht, Hatch zum Beispiel ist eins der Tools, die ich recht häufig benutze, einfach auch nur, 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.tommel-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.

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 MK Docs, wo das dann installiert ist.

Und dann kann man halt wirklich ganz strukturiert sagen, okay, diese verschiedenen 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, PiProjector Tommel.

Das finde ich irgendwie total angenehm, weil das so viel besser nach außen kommuniziert, welche verschiedenen Gewissen.

Das ist ja 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-optionalgruppen sind halt die, die absolut notwendig sind, damit 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 Definitive.

Kann man auch vertreten?

Ja, also 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 hab, also oft hat man dann implizit ja doch mehrere, zum Beispiel, wenn man sowas wie Pre-Comit-Hooks verwendet.

Weil Pre-Comit kümmert sich ja auch wieder selber darum.

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.

Pre-Commit-MaiPi ist zum Beispiel so ein Kandidat, der unheimlich nervig ist, weil das halt.

Genau.

Also, genau, also ich würde sagen, wenn man nur Dev und Port haben will, dann schafft man das nicht, weil man hat ja zumindest noch das für Pre-Commit.

Und das heißt, dann hat man nochmal einen Ort, wo man das pflegen muss.

Es steht ja auch nicht in der Pi Project Tonle drin, sondern es steht dann halt wieder in einem Pre-Commit-Jammel und Jammel.

Bei mir sind 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 gut, so Dokumentation, dann muss er die.

An der Stelle würde ich sagen, beschränk dich doch bitte auf Dev und Frau.

Kann man denn bei den Gruppen in Poetry dann auch Skripte für diese Gruppen definieren?

Nicht, dass ich wüsste.

Aber vielleicht betre 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 der Major Python machst, dann fliegt Poetry oft auf die Nase.

Das ist fürchterlich.

Vielleicht ist das jetzt neu besser.

Also auch noch so ein Ding, ne?

Poetry hat irgendwie zweimal ein Update gemacht, das so Breaking Changes eingebaut hat, wo es dann halt so sehr, sehr nervig.

Wirklich böse Dinge gemacht.

Ja, das war halt der Hauptgrund, warum viele Leute gesagt haben, nee, die fasse ich jetzt nicht mehr an, weil sowas geht halt eigentlich nicht.

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 das 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, dass man Poetry dann nicht mehr verwendet hat.

Ich sag mal so, andererseits, das waren halt so ein paar Sachen echt kaputt und wir haben die jetzt gefixt.

So gesehen, ne?

Wenn man jetzt einmal diesen Schwert hat und es läuft dann jetzt wieder, warum denn nicht?

Aber ja.

Ja, ich weiß nicht mehr.

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 auch, der Ton in den Requests oder den Issues war auch so ein bisschen rau, habe ich das Gefühl gehabt.

Einige Leute waren 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 Pi-Project Tommel aufschreibt.

Also in welchem Weg.

Und da wurde halt irgendwann ein Standard definiert, den die meisten Tools vertreten.

Nur Poetry hat da seine extra Wurst 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 auf das Open Issues-Ding mal angeguckt habe, dachte ich so, 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 Issues in dem Projekt.

Das ist halt so, okay, und einige schon sehr, sehr lange offen.

Und ja, naja.

Ich meine, 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 ein Problem.

Open Source schickst halt so ein bisschen.

Ja, ja, natürlich.

Wo würdest du denn den Unterschied sehen zu Hedge oder Rai?

Kann man das irgendwie kategorisieren, wo da die Unterschiede liegen?

Also ich habe so ein bisschen kategorisiert aufgrund der Dinge, die sie tun können.

Beispielsweise ist Rai 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, also

Project, Sketballing oder sowas und fürchterlich opinionated und dann so, äh.

Nein, sorry.

Kein Problem.

Genau, und da gibt es PDM, Poetry, Hatch, die nochmal 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.

So was gibt es nicht.

Und Hatch wiederum, das ist noch, also wird auch natürlich sehr aktiv entwickelt, aber das kann zum, 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 Tommel-File hinzu und macht auch, versucht die Dependency-Konflicts zu lösen.

Und das kann Hatch 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, aber ich habe es noch nicht gesehen.

Genau, ich glaube, das kommt so ein bisschen auf den Use Case drauf an.

FLIT hatten wir ja 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 Pi-Project.tommel-File eben auch das Build-Backend definiert ist.

Und da steht dann eben Poetry drin.

Vielleicht nochmal ganz kurz so zu dem Packaging.

Also ihr wollt ein Paket auf PyPy veröffentlichen.

Das ist so das, was dahinter steht.

Du meinst mit dem Publishen gerade?

Ja.

Ja, genau, stimmt.

Das kann man vielleicht nochmal einmal kurz erklären, dass man bei Packaging zwei verschiedene Schritte dann hat.

Also man kann den Bild-Schritt machen.

Das bedeutet, dass man dann, dass ein Real-File erstellt wird, was so das Format ist, mit dem das Package beschrieben wird und das 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 Schritt Step, 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 einen Wheel-File erstellt, was man da lokal hat, was andere installieren können.

Für Wheels vielleicht noch bei Windows gibt es Gulke, 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 Kompilierungstools 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.

Ja, das ist ja so viel Taschen, wenn man das irgendwann gegenhaupt, ja.

Irgendwann geht es dann vielleicht, ja.

Ich habe letztens jemand einen ganz alten Webcomic repostet auf Mastodon von 2004 oder so, wo da, 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 Vorderrund sagt so, oh, ich habe was noch viel härteres gefunden als Schmerzstöcke, irgendwie, ich installiere einfach Windows auf meinem Laptop.

Ja.

Obwohl man tatsächlich dazu sagen muss, ja, also mit den neuesten Powerchs und den neuesten Windows-Terminals und wenn man das so ein bisschen beherrscht, kann man auch ohne WSL einigermaßen gut entwickeln.

Es gibt halt so ein paar Sachen, die gibt es noch nicht, als Pakete, LFS-Event oder so, aber die meisten Sachen gehen.

Ordentlich.

Mittlerweile, würde ich jetzt behaupten, auch auf 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.

Da muss man halt einfach Docker installieren, dann laufen.

Aber auch da hast du natürlich Probleme.

Genau, ja.

Und das machst du alles ein bisschen langsamer testlich, aber es geht auch mittlerweile relativ vieles oder eigentlich alles nativ direkt.

Mit Ausnahmen.

Es gibt so ein paar Pakete, die laufen.

Ensibel zum Beispiel zickt halt rum, muss halt doch ein Docker laufen oder auf WSL 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 von total vielen Leuten genutzt wird.

Ich glaube, Armi macht das.

Das nutzt aber voll viele Leute.

Also Rust jetzt hat ja, also Armi Gronacher ist wahrscheinlich der Typ, der hat Flask gemacht, ne?

Ja, genau.

Ganz viele Projekte.

Jochen weiß er mehr.

Aber ja, also er macht jetzt gar keinen PIS mehr, hauptsächlich, wenn ich das richtig verstehe.

Ja.

Und Rust, aber er benutzt halt PIS noch manchmal.

Und dafür hat er dann in Rust so eine Lösung geschrieben, die.

Also 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, nicht ganz das, was ich brauche.

Was hat dir denn gefehlt?

Ja, also der Stil, wie?

Und also vor allen Dingen das Project Scaffolding und wo die Sachen dann liegen und so, das ist halt alles opinionated.

Ich meine, ist halt, sein gutes Recht, der 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 ich nicht mehr so gut habe.

Genau, weil im halben Jahr hat er was anderes vor, hat einen anderen Job und hat ein neues Hobby oder sowas, dann liegt es halt darum, wie es halt oft so ist.

Genau.

Und sowas wie Poetry, würde ich jetzt sagen, ist schon so lange etabliert, dass es eher sicherer ist, das auch weiterverwendet wird.

Ja, also ich habe 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.

Ja, es ist so ein bisschen, ich benutze es auch nicht pur sozusagen, sondern ich verdünne das halt dann noch so Rapper außenrum, die ich dann benutze.

Genau, also man muss sich halt seine eigenen Rapper drum bauen und das, damit das halt alles wieder irgendwie nett ist und so, dass es alles

ob man das Leuten einfach so zumuten kann,

die Frage ist halt auch da, wenn ich halt jetzt Neulinge im Projekt habe, irgendwie irgendein Junior Dev oder so, in dem der gerade Python das erstmal in der Hand hat, wie erkläre ich ihm das denn jetzt, ja, ich habe übrigens das gemacht, das gemacht, das gemacht, das gemacht, da wie wir oben rein und von hinten durch, dann oh, ob das aber kompliziert, dann ist halt direkt nach 10 Minuten ausgestiegen und fängt viel von vorne an.

Das glaube ich auch.

Viele der Tools benutzen auch andere Tools under the hood.

Also Ride 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 es, glaube ich, Pip oder PipEx.

Ich bin mir gar nicht sicher.

Aber viele von diesen grundlegenden Tools werden eben auch wieder verwendet und haben dann aber trotzdem diese übergeordneten Befehle wie Poetry Add.

Ja, also ja, also PipEx 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 PipX installieren oder über, ich glaube, der empfohlene Weg ist, das Installationsskript zu verwenden.

Ist es immer noch irgendwie, man nimmt die URL und pipt die nach Curl, zieht die per Curl und pipt die nach 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 dann gibt es dann irgendein Warning und es funktioniert nicht mehr und es geht kaputt.

Also es gibt übrigens auch bittere, also ja, ich meine, das ist Security-mäßig immer schon so ein bisschen fragwürdig, das so zu machen.

Aber es gibt halt auch viele Dinge, 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 ein 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 dazugeschrieben hast, sondern nur als 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 Packrol, bringst du 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.

Oder sagt ihr alles, nein, pur, da kommt nichts dran.

Das ist rein Standard-Lib.

Also ich installiere tatsächlich.

Ich versuche es tatsächlich zu vermeiden.

Also bei mir ist immer ein Django drin.

Nee, bei mir nicht.

Also ich hätte gerne immer Start-Projekt zum Beispiel.

Achso, 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 Kommandoteilen-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 festsehen 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 Projekt ein 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.

Und dann kann ich halt.

Dieses mit dem Project-Scaffolding, da habe ich auch gerade dran 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 ja 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 mit so einer Init-Flag beispielsweise, die erstellen dann das PyProject Tommel-File schon mal für einen.

Da sind dann auch viele der Tools schon konfiguriert, wie Black beispielsweise und dann auch diese Folderstruktur.

Also, das kann auch ganz nett sein, wenn man das nicht alles selbst machen will.

Ja, oder wenn man das mag, ja.

Also 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 bloatet, das haben wir früher halt so ein paar Mal öfter gemacht, aber das ist halt so viel Zeug drin, dass du halt nie brauchst, dass er alles immer wegschmeißt und rausschneiden muss.

Und deswegen ist es nicht so.

Ja, wenn man

jetzt sozusagen.

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, naja, nee, ich mach das lieber selber.

Aber das Problem ist, wenn jetzt jemand anfängt, was empfehlt man dem?

Ich würde fast sagen, gar kein Scaffold und alles selber bauen.

Ja, aber dann hat er halt eine schwere Lehrkurve erstmal vorsichtig.

Du musst alles aufräumen, ich kenne halt auch so Kundenprojekte, wo die Leute an irgendwas angefangen haben und denkst du so, oh mein Gott.

Ja, Cookie kann das 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-Projekt Templates 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 halt tatsächlich am Anfang installiert, weil ich kann einfach arbitrare Projekte mit meinem Django Template bauen.

Was also im Prinzip sowas ähnliches macht, wo einfach Ginger ersetzen für irgendwelche Python-Files und halt Diatricht-Strukturen bauen.

Mir ist fast so wie Cookie-Cutter, nicht ganz so mächtig.

Und ich brauch's halt auch nur so für kleine Sachen.

Ich mache jetzt auch nicht so mega große Dinge, aber.

Ja, und ein Problem, was man dabei hat, ist halt, was ist, wenn sich an dem Basistemplate irgendwas ändert.

Und man möchte jetzt alle Projekte, die man mit dem Template erzeugt hat, auf einen aktuellen Stand bringen.

Wie macht man denn das?

Ist eine gute Frage, ich bin da gerade dabei, mir was zu überlegen.

Und zwar ist es sowas wie, du musst dir halt den Commit merken, von dem du das Template gescaffoldet hast.

Dann musst du einen neuen Branch erstellen, musst dann den neuen Commit-Hash auschecken, machst dazu ein Div, dann hast du halt einen Div von deinem Template und dann machst du ein Rebase von deinem ganzen Projekt auf diesen Div drauf.

So ungefähr funktioniert das.

Und dafür schreibe ich gerade so ein Kommando und das funktioniert.

Okay.

Ja, und das ist, aber ja, dann ich habe es Cherry genannt.

Ich mach dann CC Cherry und dann pickt der quasi alle Challenges von meinem Template Scarfold.

Okay.

Du musst dich halt an zwei Sachen halten.

Zum Beispiel darfst du halt jetzt nicht an den Sachen, die das Template bereits halt 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 einen Core ändere.

Ich konnte ja nur Sachen dazufügen und dann sonst wird es halt immer Merch-Konflikte geben, wo du halt immer dann manuell dann 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.

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 das bei den bei diesem ganzen Tool, gibt es da auch so Funktionalitäten für, ich habe jetzt irgendwie 30 Repositories, die alle relativ ähnlich sind.

Ich würde jetzt gerne zum Beispiel, weiß ich nicht, Poetry-Update oder was auch immer, mal auf allen ausführen.

Gibt es da Support?

Ich hätte den Fall noch nie, das kann gut sein.

Also habe ich noch nie ausprobiert, aufprobieren müssen.

Ja, ich kenne das auch mal so, dass dann Leute sich ihre eigenen Dinge zum Verwalten von vielen Projekten schreiben.

Aber.

Also ich glaube, das ist sehr gefährlich.

Also weil die Projekte alle so unterschiedlich sind, da alle gleichzeitig anfassen.

Ja, also zum Beispiel, also in der letzten Jungle-Chat-Episode wurde Adam Johnson gefragt, wie er das denn oder hinkriegt, dass er irgendwie 70 populäre Repositories maintained oder gibt ja Leute, die da ganz viel haben.

Naja, der erste Schritt ist, dass man alle Projekte irgendwie auf den gleichen Status bringen muss.

Und dann kann man mit Skripten drüber gehen.

Ja, ich habe auch so, also für die Produktivsachen so ein Ensible-Book, das halt dann hingeht und einfach Python updatet.

Also zumindest Python minor oder so oder Bugrix geht ja noch, aber wenn du halt Major bast, dann musst du halt eigentlich immer das Projekt auschecken, gucken, ob es geht.

Noch so eine Frage halt, ne?

Wie macht der es dann mit Tests für Produktion, für so Builds in verschiedenen Versionen?

Nimmt der da alle Talks oder wie macht er es am besten?

Ja, genau, also ich habe bisher immer Talks verwendet.

Auch weil es eben meistens schon, wenn man jetzt irgendwie Hatch oder ähnliches hat, dann mit konfiguriert ist.

Einfach der Einfachheit haben wir.

Ah, okay, also Hatch konfiguriert Talks auch direkt mit

Soweit ich weiß, ja.

Und dann sagt er einfach, okay, ich unterstütze bis zu dieser und dieser Version runter und dann installiert.

Also was macht Talks nochmal?

Tox macht verschiedene Pythons da.

Ja, das erzeugt dir zum Beispiel alle unterschiedlichen Virtual Ents 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?

Das ist eine gute Frage.

Ich weiß gar nicht, ob es selber die Möglichkeit hat, ob die auf der Maschine schon da sein müssen oder ob es selber oder.

Nee, nee, nicht Docker.

Docker, das glaube ich nicht, aber ich glaube, es kann die selber installieren tatsächlich.

Ich glaube, weil es nicht da sein muss, weil ich glaube, nee, ich habe wahrscheinlich alte Versionen nicht mehr, aber die Tox-Dinger testen auch gegen alte Python-Versionen und das hat eigentlich immer funktioniert.

Also ein Wahrscheinlich, also so mein Guess wäre an der Stelle, ja, Tox macht das irgendwie selber, aber ich weiß es auch nicht genau.

Okay, Boot 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-Inis so zu konfigurieren, wie ich das gerne hätte.

Und dann kann man da ja, und es dauert immer länger, als man denkt und dann funktioniert es doch nicht.

Und bei Nox kann man das halt einfach, 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 da ja der Sunk-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 Pi Env und dann alle Versionen, die du halt testen willst, einmal draufhauen und dann sagen, wo die sind.

Ja, ja, ja.

Also das finde so Backwards-Compati-Mintain auch fürchterlich, ne?

Ja, aber keine Lust zu.

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 debatten, kann man das ja gerne machen.

Aber ich meine, wenn so viele können sich ja gar nicht so unbedingt aussuchen, auf welche Python-Version sie sind und dann.

Ja, aber warum nicht?

Das ist das schon mal so ein Infrastrukturproblem, wo ich sagen würde, erstmal dieses Infrastrukturproblem 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 so oder Dinge in diesem Ökosystem, die halt nicht auf Python 3.11 laufen.

Das kannst du, geht halt doch nicht.

Ja, aber genau, aber das ist halt so ein Ding, ne?

Harte obere Abhängigkeitsschranke.

Warum laufen die nicht auf Python 311?

Ja, gut, weiß ich auch nicht so gut.

Ja, aber das ist ja genau der Punkt, weil die meistens haben ihre Top dann gesetzt.

Oder viele Pakete in diesem Data Science-Unfeld, die gehen auch nicht für Python größer 4, also größer 3, also nicht für 4.

Warum auch immer man das sagen möchte.

Ich würde sagen, warum nicht?

Wenn Python 4, vielleicht läuft das ja noch.

Mal ausprobiert.

Ja, alles nicht so einfach.

Ja, ich weiß nicht, haben wir denn irgendwie noch irgendwie ein größeres Thema bei diesem Paket Pakettierungstools, Projektmanagement?

Ich glaube, vielleicht die Quintessenz, dass es irgendwie nicht das beste Tool gibt.

Das wünschen sich irgendwie alle, aber bis können wir nicht mehr so gut.

Das wäre jetzt leider noch nicht aufgetaucht.

Genau.

Ja, und es ist eben auch schwierig, das hast du 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 da nicht wirklich dem entspricht, auch diesem Workflow oder wie es aufgebaut ist, wie man das gerne hätte und man benutzt es da nicht, dann fällt man eben doch wieder auf eines der anderen Tools zurück.

Und dadurch entsteht das auch, dass so viele Leute so viele verschiedene Tools benutzen.

Ja.

HUAC zum Beispiel oder sowas?

Das habe ich noch nie gehört.

Das ist auch so eine Rust-Implementierung von Python-Paketen für Venves und sowas.

Format Activated 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 Ents 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 WAST oder Go oder so, aber.

Also ich würde gerne noch vielleicht eins an 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, weil es gibt ja da recht viele Pakete, würde ich sagen.

Ja, also ich denke, das kommt total drauf an.

Also ob man das irgendwie gern 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 Pipe.

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.

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 Flask, 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 hintersitzt, die das eventuell noch in ihrer freien Zeit macht.

Und dass man das auch ganz, 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, fragen wir mal so, ja.

Ja.

Nee, das ist ja auch ein sehr, sehr verbreitetes Problem, dass Leute dann halt irgendwie, also dass ja, dass dann Maintainer von so Projekten verschwinden, liegt ja häufig daran, dass sie das dann halt irgendwie hinkriegen, aber man kriegt das halt dann nur eine Zeit lang irgendwie hin und irgendwann ist 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 maintained.

Ja, vor allem, wenn der Ton dann nicht wertschätzend ist, wenn solche Ansprüche stellen und sagen, jetzt sieh aber mal zu, dass du das machst oder das 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, oder Computer und Internet und so.

Das ist eh.

Oh je.

Tja.

Ungefilterte Menschen aufeinander loslassen.

Tja.

Die sich gegenseitig nicht sehen können.

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

Genau, 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 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ß, halt auch bei anderen Sachen, die ich so kennengelernt habe im Tech-Umfeld.

Ja, und man muss auch sagen, dass die Python-Community da halt ein so ein gutes Beispiel ist für wie das gut funktionieren kann.

Das ist in anderen Communities nicht unbedingt so.

Also Python ist das auch besonders angenehm, ehrlich gesagt.

Wir wartet natürlich nicht davor, irgendwie von irgendwelchen Randoms of 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.

Aber es passiert auch immer Müti und so.

Manchmal, ja,

mir passiert das nie.

Immer freundlich, immer höflich, immer gut drauf.

Ja.

Ja, ansonsten, ich weiß nicht genau, ob ich habe sonst auch nicht.

Habt ihr noch ein Packaging-Thema?

Oder ein Management von Environments-Thema?

Nee, aber ansonsten fand dieses Automatic Speech Recognition Thema auch noch total interessant.

Also ich weiß nicht, ob du da Lust hast drüber zu reden oder.

Ich würde da super gerne drüber reden, aber ich darf leider nicht.

Achso, 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 Packaging, ich glaube, da haben wir so die meisten Tools so besprochen.

Es gibt noch so ein paar mehr, die wir jetzt nicht vorgesprochen haben.

Ja, aber ich glaube, weiß auch nicht, ob die wichtig sind oder relevant.

Wir können ja auch einfach den Vortrag verlinken oder auch den Blogposter.

Das hat 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, Piflow 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 doch 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, ja.

Ja, ich würde auch sagen, tatsächlich, also insgesamt bei Libraries so ein bisschen die Frage.

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

Und ja.

Ja, absolut.

Ja, das ist halt immer so ein bisschen, ja, irgendwie, es ist ein nicht unerhebliches Feature, dass Dinge halt langweilig, boring und alt sind.

Das kann auch sehr, sehr gut sein, ja.

Ja, alleine schon auch, weil dann man in den Issues ja häufig, 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 ChatGPT 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 zu ergibt, 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, mich, ich persönlich krieg immer, wenn halt irgendwie so Venture Capital ins Spiel kommt, dann denke ich mir immer so, oh nein.

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, jujuhu, 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-Af.

Du hast natürlich einerseits interessengeleitete Entwicklungen 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 das 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 die Geschäftsmodelle dann so zufällig anpassen.

Ja.

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 einer Community, wo nicht eine Firma dahinter steht.

Und wenn man halt eine Firma hat, dann ist immer tendenziell eher kurzlebiger, weil vielleicht haben Firmen dann auch mal andere Prioritäten, andere Interessen.

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.

Und da, ähm, das muss halt ganz viele Open Source oder irgendwie so Indie-Studios, die haben halt auf Unity gesetzt und halt da ihre Spiele halt 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 blöd geknallt.

Ich würde sagen, es 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 aber halt auch eine Chance, ne?

Aus diesem, ich mache das als mein Hobby und da passiert immer so ein bisschen

rauszukommen, weil das so nicht.

Ja, natürlich.

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 gegegnet 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 Erwerbstätigkeit nachzugehen, die irgendwie Einkommen erwirtschaftet.

Und wenn das halt mit Open Source nicht geht, ist es halt schwierig.

Also, ich versuche auch immer tatsächlich, so 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 immer so, ja, ja, total tolle Ideen, würde ich auch total gerne machen, aber nein.

Passiert eher selten leider.

Ja, den ist ja immer egal.

Du müsste halt einen Grund dafür liefern können.

Und das ist, glaube ich, halt auch eines der Dinge, wo man sich über Sachen überlegen müsste, wie man das hin.

Also ich meine, es gibt ja diverse Ideen.

Ah, ich finde übrigens, genau, dieses Material-Theme für MK Docs, du hattest das eben erwähnt.

Da der Autor davon, der hat einen sehr schönen Weg gefunden, um damit Geld zu.

Der lebt ausschließlich davon.

Und der hat lebt eigentlich quasi davon, dass er 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.

Ja, also dann, weil dann.

Also ich finde, ich finde auch diese, also ich muss halt auch darauf angewiesen sein, dass ich jetzt mit Open Source Software, die ich benutze, dass ich die für alles benutzen kann, also auch für Business, weil sonst kann ich die halt für meine Arbeit nicht verwenden, ja.

Was aber halt doof ist, halt, wenn es halt nie, wenn irgendjemand damit richtig viel Geld mit, wenn die den halt nicht zurückgibt, das ist halt irgendwie so der Deal da 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, aber.

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 soll sonst ein Distanzprobleme kriegen.

Die ich halt nicht haben darf, deswegen kann ich die Software mit AGPL nicht verwenden für Arbeitsprojekte, sondern nur irgendwie 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 ist notwendig, aber schwierig, ja, weil du halt davon abgewiesen hast, dass halt so dieses Spendending nicht.

Eigentlich, also meiner Meinung nach müsste so der Staat so ein bisschen mit der Gießkanne vielleicht sogar dahingehen und was machen.

Gerade bei Umsource.

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 dacht, okay, es gibt jetzt 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 ist halt das Problem, das zu erklären, ist halt so schwer.

Aber ja, vielleicht wäre tatsächlich einfach das mit Steuergeld.

Aber ja, ich sehe nicht, dass das passiert.

Habt ihr einen Pick der Woche?

Pick der Folge.

Oh.

Hab ich irgendwelche Picks?

Ich muss immer nachdenken.

Hast du schon einen?

Was ist tatsächlich mit Django Neapolitan?

Ah, ja.

Kennt ihr das?

Nee.

Aber ich bin auch sehr lange Django noch nicht benutzt, genau, ja.

Ja, also guck mal rein.

Okay.

Ja, wenn man jetzt Django sonst nicht macht, dann bringt einem das noch nicht so viel.

Will ich auch sagen, alles ist Quad, wenn man halt irgendwie meistens hat man ja irgendwie so sein Quad-Template irgendwo liegen oder sowas und hast das 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 Dinger 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.

Man ändert da an dieser Stelle seine Meinung auch immer, wie seine Posen, weil ab und zu reden wir mal drüber, dass die Class-Base-Views.

Nein, okay, nicht ganz.

Aber also ich mag Class-Based-Views hinter immer noch sehr gerne.

Ja, also ich finde Class-Base-Views im Prinzip auch nicht schlecht, nur die sind schon sehr kompliziert und quasi Vererbungshierarchien sind halt auch etwas.

Ja, aber dann machst du halt einfach keine Vererbung, sondern erbst halt einfach noch von einem View und dann hast du aber eine wunderschöne.

Naja, aber das Ding verab halt von Vererbunden.

Also wenn du wenn du den Formview nimmst, der erbt halt von fünf unterschiedlichen Sachen und das ist halt echt.

Ja, der ist halt kein Form View.

Ja, gut, okay, klar.

Aber also die Class-Base-Views sind halt so komplizierte Vererbungshierarchie und man braucht dann halt sowas wie Classic Class-Base-Views.

Irgendwie gibt es so eine schöne Seite, wo man dann halt sehen kann.

Okay, ja.

Und es ist halt vielleicht einfach ein bisschen viel.

Und deswegen sind viele auf der, nee, ich verwende nur Funktionen als Videos.

Ach ja, man hat halt if-Request, Message, Post und sowas, ab bohr.

Ja.

Hat dann auch Nachteile.

Klar.

Und jetzt ist die Frage, gibt es was dazwischen?

Und genau, es gab dann mal irgendwann von Tom Christie Vanilla-Views, sozusagen, um halt diese ausufernde Vererbungshierarchie in den Griff zu kriegen.

Aber das ist halt ein bisschen sehr wenig.

Und dann war halt sozusagen die Idee, der Neapolitan war halt, naja, 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, First 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 Vanille, aber nicht sehr viel mehr.

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 Dokumentation bauen kann.

Was doch meiner Erfahrung nach viel zu selten gemacht wird.

Mit was ist die Basis auf Markdown?

Genau.

Und dann kann man die Dokumentation mit in seinem Repo haben.

Ich habe das so häufig schon mitgekriegt in Kundenprojekten, dass es überall verteilt war.

Manchmal statt 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 Documentation zu gestalten.

Manchmal.

Würde ich auch bevorzugen, irgendwas Pfings 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, war das halt immer, 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, wundervolles Wort Lengi Flavor, das Gemüse-Kauchbuch.

Und zwar gibt es den, äh, gibt es ein schönes, wenn man, wenn man auf Mac ist, gibt es eine sehr, sehr schöne App, die nennt sich Paprika Recept Manager.

Und genau, das verwende ich seit einiger Zeit und finde das 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, tape ich mich auch dabei.

Aber ist gut, dass ihr das nochmal gesagt habt, weil ich hatte es nicht mehr auf dem Schirm und das gucke ich mir ins meinen Titel.

Also ich finde, manchmal müssen wir einige schöne Sachen nochmal ein paar Mal erfüllen.

Man kann Dinge auch öfter sagen, ja.

Wer weiß denn, wenn wer immer bis zum Ende von jeder Folge bleibt, und wenn wir gerade so spannende Folgen haben, wie wir manchmal haben wir auch spannende Folgen, dann wer weiß, wie viele Leute am Ende noch übrig sind.

Genau.

Ja, dann ganz vielen herzlichen Dank an der Nina zu dafür.

Vielen Dank.

Danke, dass ihr mich eingelabt.

Und ja, darf uns geflogen, schaltet uns weiter rein, morgens abends und so weiter.

Und wir wünschen euch eine wunderschöne gute Zeit.

Und bis zum nächsten Mal.

Und hoffentlich bis in gar nicht mal allzu langer Zeit.

Ja, diesmal lassen wir jetzt nicht so viel Zeit.

Ja, wir haben auch so ein paar Sachen Ideen.

Gut, bis dann.

Tschüss.

Tschüss.