Transcript: 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 dazwischengekommen.

Das haben uns auch schon viele Leute geschrieben.

Wir loben Besserung, ja. Liebe Grüße.

Genau. Danke für die Erinnerung, dass wir mal irgendwie wieder was machen sollen.

Wir wollen heute über Environment Management und Packaging sprechen.

Und wir haben die Annalena heute sogar. Hallo, Annalena.

Ja, hallo.

Hi, ihr beiden.

Magst du kurz was über dich erzählen vielleicht? Vielleicht fangen wir so an.

Ja, na klar. Genau, mein Name ist Annalena Popkes.

Ich arbeite als Machine Learning Engineer bei einem deutschen Unternehmen, das nennt sich Innovex.

Und bin da in verschiedenen Kundenprojekten unterwegs.

Je nachdem, was der Kunde möchte, mache ich verschiedene Dinge.

Manchmal auch reines Data Engineering.

Jetzt gerade bin ich bei Bubble.

Das ist ein Unternehmen, was Sprachen beibringt.

Kennt ihr vielleicht auch schon.

Habt ihr vielleicht selbst schon mal benutzt.

Und ich arbeite da im Speech Recognition Team.

Und helfe da dem Team dabei, ihre Software weiterzuentwickeln, produktiv zu nehmen und was da alles so dazukommt.

Oh ja, sehr cool.

Klingt echt total interessant.

Ja, finde ich gut.

Ist super spannend.

Ja, ist auch ein ganz interessantes Unternehmen, finde ich, wenn man dann mal etwas mitarbeitet, was auch wirklich beim User Verwendung findet.

Das ist sehr unterschiedlich, was man da für Kundenprojekte hat, was passiert mit dem Code, den man da so schreibt.

Und das finde ich total...

Rewarding, also, dass es einem viel zurückgibt, an etwas mitzuarbeiten, was man auch vielleicht selbst schon mal benutzt hat.

Ja, stimmt, das ist gut.

Und dabei bist du auch über Environment-Management-Packaging-Zeugs gestoßen oder gestolpert, oder ist das ein Hobby von dir?

Nee, das war bei einem vorherigen Kundenprojekt.

Da wurde ich gefragt, also Packaging ist ja sehr präsent, wenn man viel mit Python macht und dementsprechend ist mir das schon vorher begegnet.

Aber ich habe mich da noch nie so wirklich reingearbeitet gehabt.

Aber in einem vorherigen Kundenprojekt.

Wurde ich dann mal gefragt, welches Packaging Tool sollen wir denn benutzen?

Es gibt ja so viele.

Und dann hatte ich angefangen, mich mal ein bisschen reinzulesen und dachte, boah, ich finde wirklich viele Blogartikel zu den einzelnen Tools.

Aber ich finde nicht so wirklich einen Artikel, der die verschiedenen Tools zusammenfasst, mal kurz erklärt, was sie können, wozu sie geeignet sind und das Ganze vernünftig kategorisiert.

Vor allem ohne diese persönliche Präferenz reinzubringen, die man ganz viel findet, die ich auch ganz viel...

Ja.

Unter Kollegen halt bemerkt habe, dass manche sagen, ja, Poetry auf keinen Fall will ich nicht benutzen.

Die haben da mal so ein Release rausgebracht und der hat total viel kaputt gemacht.

Und nee, das mache ich jetzt kategorisch nicht mehr.

Ja, das sagt Jürgen auch.

Ich benutze es noch.

Wir hauen uns da im Karten.

Und dementsprechend dachte ich dann, okay, jetzt wird es mal Zeit.

Das ist eine gute Möglichkeit, mich da mal tiefer reinzuarbeiten, da auch einen Talk zuzumachen und einen Blog zu schreiben, einen Blogpost zu schreiben.

Und das habe ich dann gemacht.

Und das hat erstaunlich viel Anklang gefunden.

Wobei, wenn man jetzt so darüber nachdenkt.

Wahrscheinlich gar nicht so erstaunlich, weil das ein Problem ist, was so viele Leute betrifft.

Ja.

Und das Ganze...

Also ich würde ausdrücken, das ist so das Hauptproblem, wenn ich halt auch einen Neuling oder sowas versuche, Python beizubringen oder irgendwie irgendwas zu zeigen.

Das ist immer eine große Hürde, bis erstmal alles läuft und bis man irgendwelche Environments erstellen kann und so weiter.

Und jetzt reden wir ja noch nicht über Packaging, aber einfach nur dieses Environment-Setup in Python ist so ein bisschen nervig.

Ja.

Und nicht nur ein bisschen, sondern sogar ziemlich nervig.

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

Auf deine Meinung.

Persönliche Präferenz, was du sagen würdest, was so am besten funktioniert.

Aber ich finde das cool, dass wir diese ganzen Tools haben und vielleicht können wir über die einzelnen Tools noch irgendwie reden.

Normalerweise machen wir es ja immer so, dass wir einen großen News-Teil vorne haben, aber da wir halt seit Mai, glaube ich, keine Folge mehr hatten, da hat sich da so einiges eingesammelt.

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

Das müssen wir, glaube ich, an einer anderen Stelle nochmal so ein bisschen nachholen.

Aber gut, so ein bisschen was können wir ja machen.

Ach, doch so ein bisschen was.

Ja.

Na gut.

Worüber willst du erzählen?

Ich weiß es nicht.

Einfach nur das, was mich in letzter Zeit so ein bisschen beschäftigt.

Oder wo ich dachte...

Okay, kann ich jetzt was zu sagen, weil es mich gerade betroffen hat?

Zum Beispiel, es gibt irgendwie ja...

Also, seit letztem Mal Pydentic Version 2 ist raus.

Ah, ja, natürlich.

Und jetzt inzwischen sogar 2.4.

Wir haben ja auch die ganzen Europe-Python-News noch nicht gemacht.

Ja, richtig.

Eine ganze Menge.

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

Ich wollte es eigentlich nur updaten und dann hat das halt irgendwie nicht so gut funktioniert.

An Pydentic 2 ist jetzt, dass dieses Rust-Core, das halt vorher Pydentic-Core war, also als Extra-Library jetzt mit drin ist, direkt in...

Pydentic selbst, ja.

Ja, genau.

Das heißt jetzt auch schnell.

Das ist jetzt...

Das, was vorher langsam war, das ist das Hauptproblem, was Pydentic halt so hatte bei der Validierung, geht jetzt einigermaßen flott.

Ja, sollte jetzt deutlich schneller gehen.

Ja, ja, genau.

Ja, das Problem ist halt, dass Objekte erzeugen halt, wenn man das rein in Python macht, sehr langsam ist.

Wenn man jetzt irgendwie lange Listen von 10.000 irgendwie Einträgen in einem JSON-Ding hat, dann dauert das halt irgendwie, wenn man das in Pure Python macht, das alles zu validieren.

Und in Rust geht das halt deutlich schneller.

Und, ähm, ja, aber, äh, genau, also, ähm, ach so, das hatten wir auch noch nicht erwähnt, äh, ähm, es gibt jetzt eine Firma hinter Pydentic, äh, und die hat auch irgendwie, glaube ich, von Sequoia oder so, ordentlich Venture-Craft-Value bekommen.

Mhm.

Und die Entwicklung...

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

Hatten wir schon erwähnt, ach so, gut.

Kann sein.

Habt ihr schon erwähnt, ja.

Ja.

Äh, okay, genau, aber die Entwicklung geht da jetzt auch deutlich schneller und, ähm, genau, das Update, das ich dann jetzt probiert habe, war aber nicht so reibungslos.

Das war halt echt, das war richtig übel.

Das hat deutlich länger gedauert, als ich so gedacht hätte.

Ich meine, das ist halt auch so ein Ding, äh, das kann dann passieren, wenn man Dinge ändert, ne, da halt halt irgendwie, früher war es halt so, dass, wenn man, äh, bei einer, ähm, äh, bei so einem Feld gesagt hat, typing any, dann war das default-mäßig none.

Mhm.

Und, ähm, das ist es jetzt nicht mehr.

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

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

Und dann musste ich halt irgendwie, weil das, es hat sich auch noch ganz viel anderes Zeug geändert.

Ich dachte so, welche Änderung hat das jetzt verursacht, dass ich da jetzt immer einen Fehler kriege?

Und ich habe wirklich lange suchen müssen, bis ich das rausgekriegt habe, dass das der Grund war.

Manche Sachen sind gemein, die beißen einen.

Äh, ja, das war schon, dachte ich so, mhm, ja.

Aber im Grunde ist das natürlich eine tolle Sache, dass das jetzt irgendwie alles irgendwie auch schnell funktioniert und so.

Ja.

Aber ich werde wahrscheinlich noch ein bisschen, bisschen brauchen, bis ich alle Sachen, die ich, wo ich Freidentik verwende, da umgezogen habe.

Benutzt du das auch in Django?

Ähm, ja, ich benutze es in Django-Projekten teilweise auch, wenn halt vor allen Dingen Daten von außen irgendwie kommen, um die halt zu validieren, verwende ich das halt.

Also wenn es halt nicht über quasi Django REST-Framework geht.

Genau, ich wollte gerade sagen, du hast keinen Django REST-Framework.

Doch, also für, für, für, für so REST-Apps nehme ich normalerweise Django REST-Framework, aber manchmal kommen Daten ja auch von woanders und dann, dann nehme ich schon ein paar Identik.

Aber da gab es ja auch ein paar News zu, ne? Ich glaube, REST-Framework wird irgendwann duplicated und nach Django reinwandern, irgendwie jetzt mit 5 sogar schon, dann.

Ja, das weiß ich nicht.

Das weiß ich noch nicht. Also die, die Kerngeschichten wandern in den, wandern in Django selber rein.

Ähm, ja, also quasi das Encoding-Geschichten, also es gibt, ja, größere Teile, die in Django jetzt selber sind und dann könnte man halt sowas wie Django REST-Framework relativ leicht in Django selber reinpacken.

Aber Django REST-Framework selber, glaube ich, kommt nicht, also mit allem, was so dranhängt, auch nicht rein, weil das ist halt einfach so riesig.

Ja, vielleicht, aber natürlich keine Sache, ne?

Dann kann ich dann gar nicht mehr, wenn man das einfach so reinpackt.

Dann ist es auch nicht mehr großartig, genau. Das ist halt, ja.

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

Ja, ja. Ja, also das ist auch noch interessant. Also es gibt ja dieses Django Ninja oder so.

Ja, okay, das ist komisch.

Ja?

Ja, also ich finde schon.

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

Ja, ansonsten, äh, was habe ich denn noch so? Ach ja, die LLM-Geschichte, das war ja die vorletzte Episode.

Ja, ja.

Da haben wir uns also quasi gerade mit beschäftigt.

Die eskaliert auch immer noch so munter von sich.

Und wird immer, äh, äh, da gibt es auch jede Menge Neuigkeiten. Kann man auch nicht alles abdecken, ist einfach so viel, was da passiert.

Aber, äh, ne, ne Haupt-, ne, ne, äh, wichtige neuere, äh, neuere Geschichte, die da passiert, ist halt irgendwie, und das will ich mir unbedingt angucken, hab's noch nicht geschafft.

Aber, was man jetzt machen kann, ist halt, äh, tatsächlich, äh, irgendwie mit, mit Lama 2, was halt jetzt so richtig offiziell irgendwie, ähm, dafür, äh, gedacht ist, dass man damit Dinge machen kann.

Das kann man halt super feintunen, gerade die kleineren Modelle kann man super feintunen auf irgendwelche Problematiken.

Und dann braucht man halt nur ein paar tausend Beispiele für irgendwas und kann da halt dann, ohne dass man die Daten zu OpenAI schickt oder sonst irgendwo hin, äh, irgendwie Dinge damit machen.

Mit guten Ergebnissen.

Mit sehr guten Ergebnissen. Es gibt ganz viele Leute, die davon total schwärmen und die sagen, das ist total super.

Irgendwie, wenn du da in der Richtung irgendwas machen kannst, lass alles stehen und liegen und mach das, weil das ist halt so großartig.

Ja.

Ja, okay.

Daher, ähm, ja.

Hab ich mir auch schon gedacht und gedacht, nee, mach ich nicht, aber.

Ja.

Ich würd gern.

Naja.

Ja.

Weißt du, was ich rausgekommen bin?

Von dem, wofür man LLMs noch wunderbar benutzen kann, wo ich sehr überrascht war?

Nee.

Sag mal.

Musiktipps.

Musiktipps?

Ja.

Okay.

Das fand ich hervorragend.

Also, also, fast mit das Beste, was du hast.

Du hörst irgendwas Schönes und gibst dann halt so das, was du magst.

Aber als Kontext, wenn du sagst, hey, ich hör das und das gerne, hast du ein paar gute Tipps, was rauskommt.

Also, ich fand die Tipps hervorragend.

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

Cool.

Hab ich noch nicht verwendet für, aber klingt, äh, klingt gut.

Ja, muss ich mal probieren.

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

Ach, echt?

LLMs for Music Recommendation.

Ja.

Ach, witzig.

Toll.

Ich hab, ich hab's nicht gesehen.

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

Nein, hab ich tatsächlich nicht gesehen.

Sonst hätte ich den auch jetzt empfohlen.

Aber den hab ich tatsächlich verpasst.

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

Ah, gut.

Okay, also auch noch, das musst du auf jeden Fall auch in die Show-Notes, ne?

Dann können wir nochmal die Europython-Talks verlinken.

Ja.

Genau.

Ansonsten, ja, äh, Postkarten.

Das 16 ist raus.

Ist jetzt zwar nicht so wirklich was mit Python zu tun, aber, äh, vielleicht, äh, ja, die

meisten Leute, oder, dürften ja auch irgendwie den Datenbank verwenden und viele verwenden

wahrscheinlich Postgres und da hab ich jetzt auch meine, meine ganzen Geschichten geupdatet

und, äh, das ging auch problemlos.

Also von, von 15 nach 16, wenn der PG-Upgrade einfach drüberlaufen lässt, das hat einfach

immer so funktioniert, auch mit 14.

Also es war ein sehr problemloses Update.

Mhm.

Für mich.

Und, ähm, ja.

Hat auch eine Menge nette Sachen drin.

Boah.

Also ansonsten, weiß nicht, habt, habt ihr vielleicht noch irgendwas, was euch einfällt,

was man mal erwähnen könnte, was in letzter Zeit Interessantes passiert ist?

Ich bekomme vor allem durch die Arbeit viel mit über die Large-Language-Modelle, aber

du hast ja auch gerade so gesagt, das sprengt absolut den Rahmen.

Wir haben da auch einen Channel zu bei der Arbeit, ähm, und da sind täglich mehrere

Posts, also da kommt man überhaupt nicht hinterher, weder sich das alles anzulesen noch, also

ich bekomme die großen Releases mit von den Modellen, aber darüber hinaus finde ich

schon fast, könnte ich fast den halben Tag damit verbringen, Artikel zu lesen zu den

verschiedenen Dingen, die da passieren.

Ja, ja.

Das ist halt mal so.

Ja, ja, ist aber die Frage, was dann die richtige Strategie ist, ob man irgendwie dann mitmacht

oder sagt, naja gut, jetzt warten wir erstmal ein paar Monate, bis sich das alles so ein

bisschen gesettelt hat und dann die Sachen, die halt dann als sich als, äh, das wird

bleiben oder es nicht so, äh, es nicht nur Hype irgendwie erwiesen haben, da, sich das

dann nochmal anzugucken.

Ich weiß es nicht.

Ah.

Schwierig.

Schwierig.

Ja.

Äh, ja gut, aber ansonsten.

Ja, ich würde, meine News sind alle so, gerade nicht so technisch, natürlich, deswegen

skippen wir die für heute einfach mal.

Okay.

Jut, jut, jut.

Ja, dann können wir ja eigentlich direkt zum Thema übergehen, nahtlos.

Wollen wir mit Environment anfangen oder mit Packaging?

Ich würde sagen Environment, oder?

Ja.

Hätte ich auch gesagt, ja.

Okay.

Ähm, wollt ihr auch über das Python Version Management reden?

Das hatte ich auch als Kategorie noch mit aufgenommen.

Ja, also Finte gehört auch dazu und das überschneidet sich.

Das überschneidet sich ja teilweise auch, weil auch PyEnv ja Virtual Environments macht

und so, wenn man, wenn man will.

Ja.

Ja.

PyEnv ist vielleicht ein guter Anstieg, also weil ich würde tatsächlich mit PyEnv wahrscheinlich

anfangen auf so einem System, um Python selber zu installieren.

Ich würde das halt nicht irgendwie über die Website machen, sondern tatsächlich irgendwie

versuchen, PyEnv irgendwie zu klonen und dann in den Pfad zu packen und dann halt verschiedene

PyThons installieren zu können.

Das funktioniert ja leider nicht so gut auf, auf Windows-Maschinen, sondern halt nur auf

POSIX.

Es gibt aber so ein Fork.

Der das auch für Windows macht, der in den letzten Jahren so ein bisschen besser geworden

ist und es ist jetzt einigermaßen benutzbar, aber es hat halt nicht so schöne Sachen auch

drin wie Minikonda oder sowas, was ja bei der POSIX ganz gut funktioniert.

Ich weiß nicht, ob ihr.

Bin auch ganz froh, dass ich meistens mit einer Linux-Maschine arbeiten kann und nicht

unbedingt auf Windows zurückgreifen muss, da ist es häufig ein bisschen leichter, alles

aufzusetzen.

Ja, also es ist in den letzten Jahren ein bisschen besser geworden.

Ich muss das halt recht häufig machen, aber es geht mittlerweile.

Also ja, ich weiß nicht.

Vielleicht.

Das geht ja auch an mit PyEnv.

Also ich würde tatsächlich PyEnv installieren und dann mit PyEnv die Python-Version installieren,

die das Projekt gerade haben will.

Genau.

Ich weiß auch gar nicht, ob viele Einsteiger bei eurem Podcast dabei sind.

Also vielleicht können wir auch immer noch mal sagen, was die Tools überhaupt machen.

Ja.

So zur Vollständigkeit.

Sonst sind sie alle wieder direkt aufgeschaltet.

Oh ja.

Das Feedback habe ich schon ein paar Mal bekommen.

Das war aber ganz schön schwierig.

Ja, genau.

Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt

habe.

Das war ganz schön schwierig, ja.

Ja, genau.

Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt

habe.

Das war ganz schön schwierig, ja.

Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt

habe.

Also ich hatte am Anfang überlegt, als ich mich mit der Thematik der Art und Weise beschäftigt

habe, ob es Kategorien gibt, weil bei Python gibt es eben unheimlich viele Tools, die alle

verschiedene Dinge können und manche können mehrere Sachen und eine bestimmte Kategorie

ist eben Python Version Management, sprich, dass man ein Tool hat, das einem erlaubt,

verschiedene Python-Versionen herunterzuladen oder zu installieren, ohne dass man das manuell

machen muss und dann, dass man eben auch leicht zwischen den Versionen wechseln kann.

Und PyEnv ist so das bekannteste Tool, glaube ich, dafür und auch eines der wenigen Tools,

das es wirklich macht, viele, die das, also zum Beispiel Rye ist so ein Multi-Purpose-Tool,

was viele verschiedene Dinge kann, aber sonst die meisten können gut mit PyEnv interagieren,

also man kann beides zusammen nutzen, aber PyEnv ist, glaube ich, so das Tool und auch

ziemlich leicht zu benutzen, wenn man es erst mal installiert hat, gibt es einfache Befehle,

womit man dann einfach spezifizieren kann.

Ich möchte gerne Version 3.10.4 und dann installiert es die Version und man kann leicht

zwischen der und anderen Versionen hin und her wechseln.

Ja, also ich brauche es auch genau, also lokal, wenn ich irgendwie auf einer Entwicklungsmaschine

unterwegs bin, da ist das halt etwas, was ich auch ständig brauche, weil viele, also

ich arbeite ja auch für unterschiedliche Kunden mit unterschiedlichen Python-Versionen

teilweise und wenn man halt ein Virtual Env mit einer bestimmten Python-Version haben

möchte, dann ist halt PyEnv genau das, was man dann an der Stelle haben möchte.

Ich glaube, es gibt noch ASDF zum Beispiel.

Das macht das dann halt nicht nur für Python, sondern halt auch noch für quasi Node.js und

für Ruby oder sowas.

Keine Ahnung, habe ich dann nicht probiert, weil den Anwendungsfall habe ich so selten,

dass ich das nicht brauche.

Und genau, es macht halt auch so Dinge wie, also PyEnv macht auch noch so Sachen wie, man

kann halt Minikonda, also es gibt ja auch so ganz unterschiedliche Python-Ökosysteme,

also je nachdem, also wenn man im Data-Science-Umfeld unterwegs ist, da ist halt

eher so Conda, das Tool, was man benutzt, um halt Applikigkeiten zu installieren und

vielleicht will man halt dann eher so die Minikonda-Python-Version haben, was wieder

was anderes ist als diese komplette Anaconda-Distribution, das habe ich auch schon ganz oft gesehen, dass

Leute mit der anfangen und das dann halt für Sachen verwenden, wo ich denken würde, oh

nein, da brauchst du eigentlich Minikonda und irgendwie ein Virtual Env oder so, kannst

das komplette Ding, ist halt, ja.

Das ist oft halt so ein Einstiegspunkt, weil das halt oft in der Data-Science-Welt irgendwie

sehr empfohlen wird als Entry-Point.

Ja, ja.

Kann man mit PyEnv auch die ganzen Dialekte installieren?

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

Das weiß ich nicht, also PyPy geht, ich glaube, Logel geht, aber…

Habe ich tatsächlich auch noch nie ausprobiert.

Keine Ahnung.

Ich habe auch gerade gedacht, dass so über Conda, Minikonda, Anaconda könnt ihr wahrscheinlich

auch sogar eine ganze Semper-Art-Folge machen.

Ja, wahrscheinlich, oh Gott, du musst nicht zu tief da abschweifen, weil, ja.

Genau, ja, Conda ist ja wirklich so ein ganz eigenes Ökosystem, ein bisschen, wo man dann

doch mal, das lohnt sich schon, finde ich, tiefer einzusteigen, damit man zumindest mal

einmal versteht, was der Unterschied zwischen Conda, Anaconda, Minikonda und so weiter ist.

Aber es ist schon wirklich ein riesengroßes Themengebiet.

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

Vielleicht haben wir das einmal so kurz so als Elevator.

Ja, also aus meiner Sicht, der Hauptunterschied ist, dass beim Virtual Env, bei dem normalen

Virtual Env in Python, da ist der Interpreter halt nicht mit dabei, sondern man verwendet

halt alle Virtual Envs.

Wir verwenden den gleichen Interpreter, die halt mit dem gleichen Interpreter erzeugt worden

sind.

Vielleicht nochmal ganz, ganz anstrengend, also ein Virtual Env ist tatsächlich eine

virtuelle, erzeugte Umgebung für das Python, für dein eigenes Projekt.

Ja, also es ist so ein bisschen Magie, dass man die Pfade umbiegt, aber das hat den Effekt,

dass man alles, was man da drin, also wenn man jetzt irgendwas mit PIP-Install irgendwas,

eine Abhängigkeit installiert, dass die halt nur in dem Environment tatsächlich installiert

ist und nicht in allen, die man sonst irgendwie, also sonst halt nicht, sodass ich halt, wenn

man jetzt mehrere Projekte hat, dann kommen die sich ja sonst in die Quere, wenn man halt

in dem einen irgendwie, weiß ich nicht, Django 3 hat und im anderen Django 4, dann, die werden

sozusagen im gleichen, ja, auf dem gleichen Isolationslevel, dann würde man ja quasi

die Abhängigkeiten vom einen kaputt machen, wenn man im anderen was ändert und um das

voneinander zu isolieren, nimmt man halt Virtual Envs, üblicherweise.

Und ja, das ist halt sozusagen, Virtual Env ist so der, die leichtgewichtigste Art von

Isolation, weil der Interpreter ist, wenn man jetzt zwei unterschiedliche Projekte mit

zwei unterschiedlichen Virtual Envs hat, ist man halt noch gleich, aber die Pakete, die

installiert sind, sind halt gleich.

Genau, das ist ja auch ein Bild, ne, Python-M, Venv und dann Sachen.

Genau, bei Conda ist das anders, da ist der Interpreter tatsächlich mit dabei, das heißt,

auch die Interpreter sind voneinander getrennt und man kann mit Conda nicht nur Python-Pakete

installieren oder Python-Reels, sondern man kann halt auch andere Geschichten installieren,

das heißt, man kann zum Beispiel, das ist halt, deswegen ist das auch bei Data Science

immer so ein, so ein, so ein, aber das braucht man halt einfach häufig, häufig hat man

halt nicht so einen direkten Zugang zu den Maschinen, auf denen man irgendwie Dinge macht

und dann kann es schon mal sein, dass man dann eine alte LibC hat oder sonst irgendwas

und, oder alte Bibliotheken, die man nicht verwenden möchte und man kommt halt, man

hat ja gar nicht die Berechtigung, das sozusagen auf Systemlevel zu ändern und dann kann man

das mit Conda aber meistens schon irgendwie hinkriegen, dass man das halt dann, dass man

dann halt eine eigene Grundlagenbibliothek irgendwie mit installiert und die dann verwendet,

wird, statt dem, was auf dem System drauf ist, das geht mit Conda, das geht mit PIP nicht

und daher ist das halt etwas, was man halt, wenn man diese Probleme hat, dann, also wenn

man Webentwicklung macht, hat man diese Probleme normalerweise nicht, aber bei Data Science

kann das durchaus schon mal vorkommen und dann ist Conda da einfach das Ding, womit

man Sachen hinkriegt, die dann mit PIP nicht gehen.

Ja, da sind wir schon direkt drin, also es gibt ja PIP, was macht PIP?

Pakete von API installieren?

Ja, genau, vom Cheese-Shop und ja.

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

sind und so und da gibt es noch ein anderes Tool für, das man häufiger nutzt, oder?

Noch eine Isolationsschicht weiter, oder noch weiter isoliert, also ein Tool, also ich würde

sagen, das nächste Tool in der Reihe wäre halt Docker.

Oder PIPX.

PIPX macht das gleich wie PIP, nur das ist halt für das, was du installierst, ein eigenes

Virtual Env erzeugt direkt.

Ja, oder es macht aber auch externe Sachen, also Sachen, die sich auf PIP einlegen und

da überziehen kannst.

Ja, okay, gut, das wusste ich gar nicht.

Ich habe gerade noch überlegt, vielleicht noch einmal zum Anaconda und Miniconda, die

Namen sagen das ja schon so ein bisschen, dass Anaconda wirklich riesig ist, das nimmt

auch unheimlich viel Speicherplatz ein, weil super viele Python-Packages, wenn man Anaconda

installiert, kommt das mit Python, dann ist Conda dabei, was ja der Package-Manager ist

von dieser Conda-Welt und aber auch super viele Packages, die man gar nicht unbedingt

braucht und dementsprechend, wenn man...

jetzt nichts dagegen hat, die Packages, die man braucht wirklich selbst zu installieren

und auch nicht unbedingt so viel freien Speicher hat, dann ist Miniconda eigentlich immer eine

gute Variante, was mit Python kommt, schon mit einer Version und eben mit Conda, mit

dem Package-Manager, sodass man die Pakete dann installieren kann, die aber von dem Conda-Index

kommen, dann nicht von PyPI.

Ja, ja, also ich denke, wenn man jetzt halt noch härter isolieren will als mit Conda,

dann wäre halt Docker das Ding, was man auch verwenden kann, was halt viele benutzen,

ja.

Ja, das ist halt langsam, aber ich finde Conda so ein bisschen intrusiv, weil Conda relativ

hart immer den Pfad direkt angreift, zumindest auf ein System und dann, ja, muss man immer

so ein bisschen aufpassen.

Ich glaube, also...

Ja, muss man bei all diesen Dingen...

Ja, generell, der Pfad ist immer so das, wofür viele Anfänger halt drüber stolpern,

wenn halt irgendwie im Pfad Dinge in der falschen Reihenfolge gesetzt sind und dann halt nicht

das Python läuft, was wir eigentlich denken, was laufen sollte und sowas, das ist so ein

bisschen hampelig.

Ja, ich habe auch mit Conda also anfangs immer angefangen, weil ich es praktisch fand, weil

so viel schon damit kam, aber mit der Zeit habe ich auch dazu gewechselt, die Python-Version

selbst zu installieren und nicht mehr auf Conda zurückzugreifen, auch weil ich das teilweise

verwirrend fand, dann manche Packages kann man gut mit Conda installieren, andere wieder

nicht.

Und dann fand ich es tatsächlich leichter, langfristig einfach die Dinge mit pip zu machen.

Aber ich weiß, dass viele Conda, vor allem wenn sie jetzt nicht aus dem Computer-Science-Bereich

kommen, doch recht hilfreich finden.

Mhm.

Ja.

Und ich weiß, dass die Leute, die mit pip auch die richtigen Build-Tools halt irgendwie

noch installiert haben als Dependencies und je nachdem, was für Dependencies dabei sind,

damit das gebaut werden kann, brauchen halt, weiß ich nicht, von C-Libraries über Haskell

oder sowas und das halt manchmal so ein bisschen anstrengend sein kann, wenn man nicht weiß,

was da passiert.

Ja, das hat alles so seine Tücken.

Ja, es ist leider kompliziert.

Ich weiß auch nicht, ich glaube nicht, dass man da, ich würde sagen, immer wenn jemand

fragt, ja, was soll ich denn nehmen, dann muss man eigentlich immer antworten, ja, hängt

davon ab, was man macht.

Und dann kann ich, ja, und das ist natürlich so ein bisschen eine doofe Situation, weil

muss man lange erklären und so.

Ja.

Ja, häufig finde ich es auch hilfreich, also ich arbeite ja immer an verschiedenen Kundenprojekten,

dementsprechend auch in verschiedenen Teams, dass die Teams sich ja häufig auch auf eine

Lösung einigen, sodass sie sich dann gegenseitig helfen können, dass dann nicht jeder sein

eigenes Setup hat, sondern dass sie sich auch vielleicht auf einen Editor einigen, den dann

alle ähnlich aufsetzen können, das ist mir schon häufiger begegnet.

Also da würde ich sagen, da gibt es immer große Widerstände, wenn man sich auf einen

Editor einigen kann.

Also es ist ganz gut, wenn die Sachen editoragnostisch funktionieren, also.

Ja, das stimmt, aber manchmal kann es auch ganz hilfreich sein, also ich finde, es kommt,

also es kommt wirklich sehr auf die Kundenprojekte auf.

Ja, solange alle Leute das so machen, wie ich das so richtig halte, ist das natürlich

so.

Ja.

Ja.

Ja, ja.

Genau.

Wo waren wir denn überhaupt?

Genau.

Wir haben Python installiert und wollen jetzt halt ein Environment haben und dann gibt es

halt verschiedene Sachen, wie man das macht und wir haben jetzt gerade.

Also was ich gerne noch zu Python sagen würde, also ich benutze das halt für Entwicklungsmaschinen,

ne.

Da habe ich halt die Python Version, produktiv mache ich das eigentlich nicht, also nicht,

wenn ich es unter Kontrolle habe, wenn andere Leute das machen, die machen manchmal auch

andere Sachen, ich habe auch schon mal Python verwendet, um halt dann auf Produktivmaschinen

Maschinen eine Python-Version zu installieren

oder so, aber das mache ich jetzt eigentlich

nicht mehr, sondern ich installiere da hart,

ich kompiliere Python. Also, das ist auch so was.

Hätte ich nicht gedacht. Also, wenn mir jemand früher

gesagt hätte, also, in

zehn Jahren, weißt du, wie du da Python installieren wirst?

Du wirst es runterladen und auf der Maschine

kompilieren. Ich dachte so, nee, das

kann nicht sein. Doch, ist aber so.

Also, das ist tatsächlich die von mir momentan

präferierte Art, Python

auf ein Produktivsystem zu installieren, ist halt

selber zu kompilieren.

Postcode und bauen, okay.

Und auch nicht Python.

Ich habe Python auch selten in Kundenprojekten

benutzt, aber wenn man es mal ausprobieren

möchte, finde ich das auch ganz

nett, sich einfach mal die neueste Python-Version

runterzuladen damit. Dann kann man das

Tool mal ausprobieren und dann mal gucken, was

die neue Python-Version so

besonders macht oder mitbringt.

Beta-Version oder Release-Kandidates oder so, das ist immer

sehr nett dafür. Genau.

Ich überlege gerade, ob ich das cool finde, dass ich das selber

kompiliere im Produktivsystem.

Warum nicht Python für ein Produktivsystem?

Naja, deswegen, weil ich,

der Grund, warum ich damit dann aufgehört habe,

ist, dass ich dann irgendwie

nach längerer Zeit gemerkt habe, dass manche Projekte

halt eine alte Python-Version

verwendet haben,

wo ich das gar nicht mehr gedacht hätte, dass sie das tun.

Und das aber alles weiter funktioniert hat.

Und ich das aber gar nicht wollte.

Und dann habe ich gesagt,

ah, ist mir doch lieber, dass halt,

weil ich hätte sowieso gerne

immer die gleichen Python-Versionen für alle.

Aber den Fall, dass ich das unterscheiden will,

den habe ich gar nicht. Aber es kann ja mal sein,

dass du irgendwie so eine harte obere Schranke hast,

weil irgendein Projekt auf eine völlig veraltete

Library dependet, die halt schade ist, aber die halt

da irgendwie jetzt drin hängt. Und jetzt musst du halt

eine alte Version nehmen. Und dann...

Ja, passiert bei meinen Sachen nie.

Okay, ja, okay. Also ich habe so ein paar

Kunden, geht das so? Ja, ja, klar.

Ja, also der Vorteil von PyInf ist halt,

ich kann halt einfach auch die Version einfach dann installieren

und wenn in meiner Production Pipeline

PyInf halt drin ist, dann ist das halt ein leichtes

mal eben da auch mehrere Projekte

mit unterschiedlichen Python-Versionen auf einem Produktivsystem

laufen zu haben. Was halt, wenn ich das alles selber

kompilieren muss, wieder Hassel ist,

muss ich das alles selber konfigurieren. Das ist ja genau das,

warum ich ja solche Tools mit möchte.

Ja, siehste? Kommt drauf an.

Ja, leider.

Tja, ja.

Ja, also...

Da wären wir bei der Hoffnung, dass es irgendwann das eine

Tool gibt, was alles macht. Ja.

Sodass man dann nicht mehr diskutieren muss.

Da gibt es ja gerade tolle Versuche drin, das zu lösen

irgendwie, ne? Also man hört immer

Rust an der Stelle und ich würde auch sagen, dass tatsächlich

vielleicht gar nicht so eine doofe Idee ist.

Ich hätte das gerne, dass Python selber das so irgendwie anbietet.

Fände ich irgendwie cool, weil diese ganzen Tools,

die es von außen gibt, die sind alle so...

Also du hast eben Rye erwähnt, das ist das

Tool von Armin Runacher, was auch in Rust geschrieben ist,

der jetzt für Rust macht, dass so seine Opinion

ist, wie man so Projekte ein...

neu baut. Ehrlicherweise,

also ich bin da so ein bisschen anderer Meinung,

wie man das richtig machen würde. Also ich mache es anders,

mein Taste ist anders. Aber das ist eigentlich

ja so was, was es halt...

Ja, was man halt will.

Du hast vielleicht noch den großen Überblick von Tools,

die man dafür verwenden kann.

Ja, genau. Also

bei Environment Management vielleicht nochmal wieder

als Einführung, falls Leute dabei sind, die

da noch nicht sich so

gut mit auskennen. Also wenn man beispielsweise an

mehreren Projekten gleichzeitig arbeitet und

dann kann das immer mal wieder

vorkommen, dass Projekte das gleiche Package brauchen,

aber in einer anderen Version. Und man möchte die Packages

eigentlich nicht direkt auf der Maschine mit

den

nativen Dingen installieren,

sondern man... Es ist immer

ganz schön, wenn man das isolieren kann. Dann kann man alle

Dependencies installieren, die man für das

Projekt braucht, ohne dass man irgendwas anderes kaputt

macht. Und dafür kann man Virtual

Environments nutzen.

Es gibt auch einen anderen Ansatz, aber die meisten

Tools benutzen Virtual Environments und erstellen

dann eben kleine isolierte Umgebungen, wo man dann

über PIP oder Conda, wie auch immer sich die

Pakete installieren kann. Und Python hat zwei Tools,

die wirklich nur für Environment Management gedacht

sind. Das ist einmal Venv. Das kommt auch direkt mit,

wenn man Python installiert. Das braucht man also nicht

zusätzlich installieren. Und Virtual Env. Ich habe beides

schon benutzt. Es ist beides recht ähnlich. Virtual Env kann

auch ein paar mehr Dinge machen als

Venv. Aber

ich könnte da jetzt nicht

eins groß über das andere empfehlen.

Vor allem, weil wenn man

noch mehr machen möchte, beispielsweise man

ein Package erstellt, dann ist es häufig hilfreich,

eins von den Tools zu benutzen, die eben auch

noch andere Dinge können. Aber ich

habe häufiger schon mal, wenn ich einfach nur ein Virtual Environment

erstellt,

erstellen wollte, Venv benutzt oder Virtual Env,

um das schnell machen zu können.

Also ich benutze versuchst dann immer noch Virtual Env

Wrapper, weil das halt dann irgendwie

nur so drei oder vier...

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

zusätzlich hat. Ehrlicherweise

auf Windows, ich muss ja, wenn ich Windows benutze,

ist das ja mal Quatsch. Da gab es irgendwie Virtual Env Wrapper PowerShell,

das irgendwie fürchterlich war. Und ich habe es mir einfach selber geschrieben, was

eigentlich nur ein Wrapper um Venv ist. Und du willst halt

sowas haben wie MK Virtual Env oder

RM Virtual Env oder LS Virtual Env,

um halt deine Virtual Envs anzuzeigen, die du hast

und die du halt einfach dann aktivieren kannst mit

sowas wie WorkOn. Also ich finde das Schönste

an Virtual Env Wrapper ist WorkOn.

Du gehst halt einfach in dein Projekt

und gibst ein WorkOn in der Shell

und die Env ist aktiviert, ohne dass du irgendwas machen musst

und das ist halt immer convenient, das zu tun.

Ah ja, benutzt aber einer von euch

eigentlich, genau, fürs Erzeugen

oder Verwalten von Virtual Envs PyEnv,

weil das könnte man ja auch machen.

Also ich habe es... Ja,

nein, also ich benutze es nicht mehr.

Ich habe es noch nie benutzt dafür.

Okay, ich habe es mal dafür benutzt und

mache es aber nicht mehr, weil

das ist...

Damit hatte sich

das erledigt, als ich dann von ZSH

auf Fisch umgestellt bin.

Die Shell und jetzt verwende ich halt zum Verwalten

der Virtual Envs Virtual Fisch,

was ich auch noch empfehlen kann, wenn man die Fischshell hat.

Ja.

Genau, nee, verwende ich auch nicht mehr.

Ja genau, also ich benutze tatsächlich für Erstellen

von Virtual Envs meistens Poetry.

Da wird gleich ein großer Aufschrei kommen,

weil da gibt es große Diskussionen um dieses Tool

und ich benutze es tatsächlich immer noch und

ja, weil das in den Projekten, ich eh eine

PyProject Hummel habe, wo die Dependencies drin definiert

sind, dann mit Poetry relativ easy geht

und wenn ich mal selber eine eigene Env kurz

brauche, dann einfach mit dem Virtual Env Wrapper

einfach mkvirtualenv Name

work on, fertig.

Ja, das ist auch das, was ich am meisten gesehen habe.

Wobei für Einsteiger, die jetzt

wirklich noch nie ein Package gemacht haben,

ist das häufig nochmal schwierig,

wenn man dann da plötzlich so ein PyProject

Atommel-File rumfliegen hat und überhaupt

nicht weiß, wirklich was das macht und wofür man

das braucht. Da kann es schon ganz hilfreich sein,

einfach mal nur diese Tools zu benutzen.

Genau. Wie Venv. Ja, das ist,

über die PyProject Hummel müssen wir glaube ich später auch nochmal sprechen,

weil es da ja auch verschiedene Ideen gibt, wie man da

strukturiert und da bin ich auch mit so Sachen, die Poetry

zum Beispiel macht, nicht so einverstanden und

da gibt es ja so ein paar Peps, die glaube ich, das

relativ besser strukturiert

hätten, glaube ich, ja.

Es gibt auch so ein paar Tools, du hattest ja gerade

einmal gefragt, die nicht nur

Environment Management machen, also natürlich auch die, die

alle Packaging machen, aber es gibt zum Beispiel PipEnv,

das ist auch schon ziemlich

alt, das Tool, was

einem dann auch noch erlaubt, also das sagt

der Name ja auch schon, dass es Pip und

Virtual Env zusammenführt

und das Ganze nochmal ein bisschen

mehr abstrahiert, also noch mehr

Funktionalitäten hat und man darüber auch Packages

installieren kann, habe ich jetzt

relativ komische Dinge.

Weiß ich nicht.

Inwiefern?

Es gab eine Zeit lang

war halt da mal so ein bisschen das Problem, was man

gehört hat, dass

das nicht richtig im Intent wäre oder so,

aber ich glaube, das ist nicht mehr so, das ist inzwischen,

weil es halt auch eins von den Projekten von,

wie heißt der noch,

Kenneth Wrights,

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

Hat das abgegeben, also ich glaube, das war mit so einer der Gründe,

wo man gesagt hat, so, äh, ii, aber

ja, wenn das jetzt in anderen Händen

liegt, müsste man das nochmal angucken.

Ja, okay, hat auch noch

so eine look-up.

Ganz viel in diesem Bereich,

da kommt es aber auch darauf an, was man gewohnt ist,

was die anderen benutzen, wenn man irgendwann

anfängt, ein Tool zu benutzen, beispielsweise, wie du das

jetzt mit Poetry genannt hast,

dann gibt es selten Grund, plötzlich auf ein Tool wie PipEnv

umzusteigen, weil

ja, also ich könnte jetzt verstehen, wenn man

dann ein anderes Packaging-Tool benutzt, also eins,

was auch mehrere Dinge kann, aber dass man

zurückgeht auf ein Tool, was weniger

kann und dann vielleicht nochmal mehr Komplexität

hinzufügt, weil PipEnv zum Beispiel

hat so eine eigene Konvention, das

ist eben schon rausgekommen, bevor

es den, ähm, Python

Enhancement Proposal gab zu

PyProject.toml-Files, dass man die benutzt

und die haben eben auch so einen eigenen

Weg, das zu machen, also

wenn man PipEnv benutzt hat, hat man plötzlich

ein Pip-File noch da und auch ein

Pip-File.log, ähm,

das finde ich teilweise

schwierig, weil

das nochmal wieder

was anderes ist.

Also ich glaube, Leute, die PipEnv schon benutzt

haben und sich damit auskennen, für die ist das

ganz nett, aber ich würde jetzt

ich persönlich niemandem empfehlen, sich das

anzugucken, sondern dann einfach direkt ein Tool wie

Poetry zu benutzen oder Rye,

Hedge, wie auch immer.

Was haltet ihr von PDM? Oder was hältst du von PDM?

Ich hab's

selbst noch nie in einem Projekt benutzt, also

in einem Kundenprojekt. Ich hab's mal selbst ausprobiert.

Darum kann ich da nicht so viel

dazu sagen. Ich hab's natürlich mir

angeschaut für den Talk und fand's jetzt ganz

cool. Ähm, aber

ich kenn auch Leute, die darauf schwören, also

die das richtig gut finden.

Ähm, man muss zu PDM aber sagen,

ich hatte das ja vorhin kurz erwähnt, dass die

meisten Tools Virtual Environments benutzen

und PDM ist eins der wenigen Tools,

die einen anderen Ansatz fahren.

Und zwar benutzen die so, benutzt

das sogenannte Local Environments.

Das war auch ein Pep, der jetzt aber abgelehnt

wurde. Ähm, und

ich glaube, am Anfang gab's darum auch

sehr viel Interesse an dem Tool, dadurch, dass es halt diesen

anderen Weg benutzt.

Bin mir nicht sicher, was jetzt passiert, dadurch, dass es abgelehnt

wurde, ob das irgendeinen Unterschied macht.

Da diese Local Environments.

Ich glaube, es gibt auch so ein paar

Tools, die das so machen.

Ja, okay. Ich kann das gar nicht.

Ja, also ein Ding,

was mir nicht so klar war, als ich

äh, also früher und jetzt,

äh, dass das, dass es viele

Dinge gibt, die sehr unterschiedlich, also ich meine, das ist natürlich

schön, wenn man ein Tool hat, das irgendwie alles macht, aber

ähm, und

das war auch einer der Gründe, warum ich irgendwann mal

äh, auch eigentlich recht begeistert war von

Poultry, dass ich das Gefühl hatte, ich muss

nur noch diese eine Geschichte irgendwie

benutzen und kann damit eigentlich alles machen, was ich

so irgendwie tun will.

Und dann merkt man aber mit der Zeit so, naja,

so richtig, so

leider sind die Sachen doch sehr unterschiedlich,

also so unterschiedlich, dass man sich dann doch dafür interessieren

muss, dass diese Abstraktion halt anfängt,

äh, zu leaken und dann, äh,

dann wird's halt hässlich.

Für mich jedenfalls. Also ich find Poultry super, weil

es halt drei Sachen für mich macht, und das sind Dependencies

zum Projekt dazufügen, Dependencies für ein Projekt,

Dependencies für ein Projekt installieren, Dependencies für ein Projekt updaten,

und das ist so das Hauptding, für das ich's benutze,

und es ist trotzdem total nervig,

und es geht immer wieder kaputt.

Schreibst du Libraries, wo du dann

Pakete erzeugst? Nein, genau, das nicht, also weil

das ist nämlich genau der Punkt, wo ich wahrscheinlich, weiß ich

nicht, ob ich Poultry für mich nehmen würde, ich hab ja

irgendwie Flit oder Hedge irgendwie besser dafür geeignet,

aber da kommen wir vielleicht auch noch drauf, wenn wir Packaging

besprechen, ähm.

Ja, weil ich würd sagen, solange man nur

Projekte hat, wo man halt

andere Abhängigkeiten reinzieht, und die man dann

halt irgendwie, äh, irgendwo installieren

oder irgendwo hindeployt und so,

da funktioniert das ganz gut, aber sobald man halt

eigene Libraries hat, wo man, äh, irgendwie

Pakete erzeugen möchte,

dann beißt einen das so ein bisschen,

dass da die Anforderungen einfach völlig anders sind

als, äh, und, ja,

also da find ich halt zum Beispiel, also da fand ich

halt Poultry macht da Ding, äh,

da hat mich sozusagen

kalt erwischt, dass, ähm,

dass die, äh,

dass das halt zwei sehr unterschiedliche Use Cases

sind, und ich dachte, ich könnte das halt für beides

gleich verwenden. So ein Paarstellenstrich hat die Kaputte

oder sowas, dann will man halt irgendwie den Pfad

für Poultry Home setzen, und dann installiert es aber

trotzdem irgendwo anders, andere Dinge hin

und sowas, das ist halt einfach total nervig

und... Ja, das Schlimmste war, dass, äh,

also bei meinem Anwendungsfall,

das hab ich wirklich nicht gewusst, äh,

und das hat halt, äh, Sachen draußen

kaputt gemacht, äh, ist halt, dass Poultry

per Default, was ja vielleicht

okay ist für Applikationen, die man irgendwo hindeployt,

eine obere, äh, eine obere Schranke

für Abhängigkeiten hat. Das kannst du aber

einstellen. Klar kann man das einstellen, ich hab's nicht gemacht.

Und wenn du jetzt ein Paket baust,

und hast da implizit obere Schranken drin,

für die Abhängigkeiten, dann ist

das für Leute, die sich, die

dein Paket als Abhängigkeit haben, halt total blöd.

Ja, obere Schranken, also da,

da war ich erst anderer Meinung, und, ähm,

das macht im Data Science Umfeld, macht das unheimlich viele,

und auch unheimlich viele Pakete, die halt obere Schranken drin haben,

und, äh, es gab diesen sehr länglichen

Blogpost dazu, den du mir geschickt hast,

äh, den wir auch nochmal verlinken können, der mich

auch überzeugt hat zu sagen, dass das wahrscheinlich eine ziemlich

doofe Idee, äh, überhaupt so eine obere Schranke

zu haben.

Interessant, dass es mir noch nie begegnet, das Problem

Ja, du,

im Data Science Umfeld tatsächlich öfter, und wenn du dann

irgendwelche neuen Versionen hast, und die

sagen, na, ich will aber nur bis Python

maximal 3.10 gehen, und du willst aber 3.11 nehmen,

dann musst du das halt irgendwie umbauen, oder sowas,

das ist halt schon ätzend.

Ja, eigentlich gar nicht so sehr dabei, sondern

eher so bei, äh, irgendwelchen

Third-Party-Geschichten, also man hat halt irgendwie

eine, irgendeine

Crypto-Library oder so, die man

halt als Abhängigkeit verwendet, wenn man irgendwas,

wenn man die für irgendwas braucht,

und dann, äh,

äh, sozusagen hat man eine implizite

obere Schranke auf der, auf

diese, auf eine Version von diesem Paket,

und jemand installiert

jetzt eine Library, die man selber irgendwie

gebaut hat, äh, und hat

aber noch eine andere, und jetzt sagt die eine

irgendwie, ich brauch aber Abversion so und so, weil

die hat halt irgendwie so eine, äh,

Funktion, die das halt benötigt, und

mein Paket, ohne dass ich das weiß, sagt,

aber ich kann nur bis zu der Version, und dann

kriegt der halt einen Konflikt. Ja, genau. Und kann's

nicht mehr installieren. Und das ist gar nicht

deswegen, weil es einen echten Konflikt gibt, sondern deswegen, weil ich

einfach nur in den Default-Einstellungen nichts geändert habe. Ja, genau.

Und das ist halt, äh, genau.

Und wenn dann Leute sagen so, ähm, dein,

dein Library ist, äh, die macht irgendwie

hier bei mir Dinge kaputt, dann, äh,

ja, das ist halt nicht so schön. Genau, und das, also im Datastandort

hatte ich das recht häufig bei irgendwie Machine Learning-Paketen,

dass du halt tatsächlich hingehen musstest, müsstest du in den Paketen

die Requirements so anpassen, dass es halt irgendwie

funktioniert, und gucken, ob's dann geht, was man halt dann auch nicht so genau

weiß. Aber das, äh, ja.

Ja.

Das, ja. Habt ihr das mal mit anderen Tools

ausprobiert, ob das Problem dann auch besteht?

Ja, besteht auch mit dem, damit.

Ähm, also,

apropos Tools, ähm, Jochen, du meinst Pip-Tools

jetzt für deine Environments?

Genau, also ich verwende jetzt unterschiedliche Dinge,

also für diese beiden unterschiedlichen Use-Cases, also wenn ich

halt eine Applikation habe, wo ich

Abhängigkeiten, also wo ich halt auch sowas wie

Log-Files, bei einer Library habe ich

ja keinen Log-File. Aber bei einer

Applikation hätte ich natürlich schon wieder einen Log-File, sodass

halt alle Entwickler irgendwie, dass ich halt weiß,

äh. Was nochmal ein Log-File ist. Ja, muss man

auch mal finden. Also ein Log-File

ist normalerweise, pinnt halt die

Dependencies und insbesondere den, den

Dependency-Grafen halt mit, für deine

Dependencies, dass halt klar ist, dass so

die Versionen und die Abhängigkeiten dieser

Pakete, die du da benutzt, auch

ähm, gepinnt sind und

meistens hashtest du die noch, das heißt, du kannst halt sehen,

ob irgendwelche Änderungen da sind, also aus der Qt-Perspektive

gar nicht so interessant. Ja, ob das, was man runtergeladen hat,

auch tatsächlich, äh, das ist, was man haben

wollte. Genau. Genau. Und

ja. Also es führt halt dazu, dass

wenn zwei Leute, ähm, sozusagen

das, äh,

Virtual-Env mit allen Environments,

äh, äh, äh. Nach dieser Anleitung,

werden installiert. Kriegen die dasselbe. Kriegen sie genau

das Gleiche. Genau. Und haben nicht unterschiedliche

Versionen von Paketen. Genau, also das ist das Hauptproblem auch,

also klassisch ist ja Requirements-TXT.

Genau. Und das, da wär's nicht so.

Da sind halt diese ganzen Subdependencies nicht enthalten

und es kann halt sein, dass wenn man Requirements-TXT

irgendwie ein Jahr später installiert, dass dann irgendwas gebrochen

ist, weil sich da. Genau, man. Abhängigkeiten

geändert haben. Man erzeugt die Requirements-TXT,

sechs Monate später kommt ein Entwickler dazu

und installiert nochmal und sagt dann, hä, das

lässt sich gar nicht mehr installieren, weil. Ja, genau.

Irgendwelche Konflikte auftreten oder es verhält sich anders.

Und das ist natürlich etwas, was man nicht haben will.

Dafür braucht man unbedingt Blog-File-Teil. Und deswegen

also diese Blog-Files sollten eigentlich meiner Meinung

nach auf jeden Fall Teil von so einem Projekt mit

sein. In welcher Form auch immer.

Ja, wird glaube ich auch immer empfohlen.

Von einer Applikation, aber eben bei einer

Library halt nicht, weil da weiß ich ja gar nicht,

was installiert wird. Ja.

Und genau, für den Anwendungsfall

nehme ich halt,

also

eine Anwendung, die ich deploye, nehme ich halt Pip-Tools

und für den, ich hab ein

Paket, wo ich ein Wheel oder irgendwas

sonst wie ein Paket veröffentlichen möchte,

nehme ich halt Flit, was

jetzt, ich gucke

manchmal so nach Hedge rüber,

bisher hatte ich noch nicht so richtig den Grund

irgendwie umzusteigen.

Ja, wenn Flit für dich funktioniert, das ist auch glaube ich

das Wichtigste, was man von dem Ganzen mitnehmen

kann. Packaging ist zwar

super messy in Python,

also es ist total schwierig

da einzusteigen, weil Python eben

nicht designt wurde mit einem Tool,

was es alles kann, wie das bei Rust ist,

weswegen ja viele Leute sehr begeistert sind von

Rust, vor allem die Python kennen, da läuft

das sehr einfach, da hast du, hat man

Cargo, was man benutzen kann

für das Packaging und dann braucht man sich

nicht die Gedanken machen über diese ganzen anderen Tools

und

verschiedene Tools bei Python lösen eben verschiedene

Probleme und Flit ist super,

wenn man ein reines Python-Paket hat und das einfach

nur bilden

möchte, also wenn man irgendwie ein Wheel-File braucht und

das vielleicht dann noch publishen will und wenn das

für einen selbst funktioniert, dann wunderbar, da kann man

das wirklich gut verwenden.

Ich habe gerade noch daran gedacht, mit den Log-Files,

was ihr gesagt hatte, mit diesem Unterschied zwischen

abstrakten und konkreten

Abhängigkeiten,

das kann man vielleicht auch noch mal

ganz gut in Verbindung mit dem PyProject-Hommelfile

erklären, weil wenn man ein Paket

baut, hat man eben PyProject-Hommelfile,

wo die ganzen, ja,

wichtigen Dinge über das Paket drinstehen,

das sind so Sachen wie

der Name, wer der Autor ist, aber

eben auch die Dependencies, dann kann man da

für manche Tools auch genau sagen,

wie die konfiguriert

sein sollen, sowas wie Black zum Beispiel,

wenn man Formatting benutzen möchte.

Man kann da auch Skripte definieren, also man kann

quasi super viel reinschreiben, dieses

PyProject-Hommel, also die ganze Konfiguration löst halt

diese Placerer an Konfigurations-Files

ab, die dann irgendwo im Projekt-Root

rumfliegen müssen, ja.

Ja, und man,

die Dependencies, die man da reinschreibt, sind aber

möglichst, ja, grob

gehalten, würde ich mal sagen, also da kann man

Ranges angeben, welche

Paketnummern gut sind, aber man sollte

nicht die, auf genau die Version pinnen,

die man haben möchte, wofür dann die

meisten Tools eben automatisiert so ein

Log-File erstellen, wie ihr das gerade beschrieben habt,

sodass man das auch noch mitgeben

kann in seinen Repository

oder Package, sodass alle

genau das gleiche Setup

reproduzieren können.

Setup ist, glaube ich, ein gutes Stichwort. Ich glaube, früher

hat Python das halt mit Setup-Py gemacht und

Setup-Tools,

dann war das halt in Python und halt nicht in dieser

deklarativen Tummel.

Ja, die Geschichte davon ist auch,

also da gibt es ja noch sehr viel mehr, es gibt auch noch

Dist-Utils und ach, was ist der Teufel?

Ja, aber genau, also von

der Setup-Py wollte man eigentlich wegkommen,

weil irgendwie, naja, gut, viele Leute

haben immer nur ihr altes

Setup-Py, was sie sich irgendwann mal irgendwie hingeschrieben haben,

halt kopiert und

das war halt so ein Problem,

deswegen, ja, musste

man quasi beliebig lange abwärtskompatibel bleiben

mit allem und

inzwischen

sollte ja eigentlich für fast alles, was

man tut, Setup-CFG ausreichen

irgendwie,

aber ja, das ist alles ein

It's a mess.

Ja, genau.

Es ist auch eben überraschend, finde ich, also das

ich habe gerade mal das PEP geöffnet

von, das ist

518, wo es darum geht, dass

pyproject.tummel eingeführt wird, das ist von

2016, also es ist schon echt eine Weile

her und trotzdem begegnet mir das immer wieder,

dass Leute noch Setup.py benutzen,

obwohl inzwischen das schon so weit verbreitet

ist, dass man eine pyproject.tummel

Datei hat, in der

man im Tummel-Format eben definiert,

wie das Paket aussieht und welche

Abhängigkeiten es hat.

Also was ich so ein bisschen anstrengend finde, ist, dass

es halt keine Referenzen gibt in diesen Tummel-Files, dass

du halt dann Redundanzen hinkriegst, wenn du mehrere

Male diesen Namen verwenden willst in unterschiedlichen

Sachen oder sowas, was manchmal so ein bisschen

schade ist, aber gut,

es gibt Schlimmeres, als dann

zweimal irgendwie den Projektnamen hinzuschreiben, aber

ja, also ich mag die pyproject.tummel

sehr gerne, ich benutze sie halt auch für alles und

ich glaube, mittlerweile sind die meisten Tools durch

irgendwelche Tricks auch dazu zu bringen,

nur noch diese pyproject.tummel zu nehmen,

also Flake oder so.

Das ist halt so ein Kandidat für, nee.

Ja, genau, aber das geht auch, da muss man halt

ein extra Paket installieren, dann geht das, das gibt halt

so ein Fork davon quasi.

PyTest oder so ist halt auch

sehr schön darüber einstellbar, MyPy,

Ruff

und deine ganzen Tools halt, ne?

Linting und sowas.

Die Skripts

finde ich auch sehr interessant, weil

da gibt es ja auch verschiedene Sachen, das noch zu lösen.

Welche Skripts man irgendwie einhängen will.

Ja, das finde ich auch ganz schön.

Ich hatte das auch jetzt gerade im Kunden

Projekt wieder, dass jemand

Makefile benutzen wollte, um

bestimmte Kommandos, die man häufig

ausführt, runterzuschreiben

oder es zu vereinfachen, weil

der Person gar nicht bewusst war, dass man das auch

im pyproject.tummel-File definieren kann.

Also wenn man zum Beispiel immer

Python-M-Unit-Test-Discover-Test

schreibt, dass man

das einfach abkürzen kann, indem man

in der pyproject.tummel ein kleines

Skript quasi definiert und dann

sagt, dieser Befehl

soll ausgeführt werden, wenn du

Hedge, jetzt als Beispiel, Hedge ist eins

von diesen Packaging-Tools und wenn du

Hedge-Run-Test

schreibst in dein Terminal, dann wird

eben dieser Befehl ausgeführt.

Finde ich unheimlich

praktisch. Habe ich schon sehr viel

benutzt, benutze ich auch sehr viel.

Ich habe mir meinen eigenen Webpack geschrieben, weil

bei mir ist es dann cc, weil

ich habe meinen c-Compiler, die

linkt und dann einfach cc-up,

cc-start, cc-test,

crawl-command. Aber man muss

dafür das Paket quasi installieren,

im aktuellen Environment.

Genau.

Ja, aber das ist halt sowas,

wenn ich jetzt in einem Projekt bin,

also sagen wir mal, ich habe ein Django-Projekt oder so,

dann installiere ich das ja gar nicht als Paket oft.

Da ist halt wieder so

diese Unterscheidung, wenn ich ein Paket entwickle,

okay, dann habe ich das normalerweise auch immer

in einer editierbaren Version

installiert im aktuellen Environment, aber

das ist wieder diese Unterscheidung zwischen

Libraries und

install-e oder sowas, also

editable installiert ist

eine der Features, die nicht jedes von

diesen Tools unterstützt. Ja, da hatte

Poetry auch lange Probleme mit, ja.

Ja.

Aber genau,

damit geht das gut. Ja, ich bin inzwischen also

gerade bei

ich bin bei einem eigenen

Skript, das ich halt in alle

Projekte reinlege oder so,

weil

es oft auch so ist, wenn man das zum ersten Mal ausführt,

dann kann ich halt so Dinge machen,

wie ich mache halt ein try-except

um Imports und wenn die da nicht da sind,

dann gucke ich halt, ob ich irgendwo das Log-File

finde und dann installiere ich das erstmal,

erzeuge ein Virtual-Env und mache halt so,

sodass halt, wenn jemand, auch wenn jemand keine Ahnung

hat, einfach irgendwas ausführt, dass es dann

trotzdem funktioniert. Das geht halt, wenn man ein eigenes Skript hat,

relativ gut, aber ansonsten

wenn man den Leuten dann noch erklären muss, nee, du musst erst das Paket

installieren und dann so, welches Paket?

Ja, das, okay, und dann ist es halt immer noch mal

eine Hürde. Ja.

Ja, ich weiß es nicht. Ich habe da auch keine gute Lösung für.

Ich habe gerade

noch daran gedacht, dass es vielleicht auch ganz hilfreich

ist, einmal zu erwähnen, dass diese

Tools, die wir jetzt gerade schon genannt haben,

sowas wie Hedge oder Poetry, PDM,

Rye, dass die für

ein dieses Virtual-Environment-Handling

machen, also dass man da gar keine Virtual-Environments

mehr selbst erstellt, sondern man

installiert das Tool und dann kann man beispielsweise

sagen, beispielsweise sagen Hedge

run und dann Python

main.py oder was auch

immer und dann

lässt Hedge dieses Skript

innerhalb eines Virtual-Environments laufen

wo all diese Dependency

die man im pyproject.toml-File definiert hat,

schon installiert sind.

Sprich, man muss das nicht mehr manuell erstellen,

dieses Virtual Environment.

Das wird dann für einen gemacht.

Mhm.

Ja, dann, also Pultree zum Beispiel,

kann man halt auch dann konfigurieren,

dass halt alle WEMFs in einem bestimmten Ordner liegen,

wenn man das gerne hätte.

Oder dass die halt im Projekt liegen.

Also das gibt halt diese zwei Varianten.

Ich weiß nicht, wozu ihr da tendiert.

Vielleicht auch ein bisschen die Frage,

ob man ein Dev macht,

wo man halt zwischen den WEMFs vergleichen will

oder ob man das halt in ein Pod macht,

wo man das vielleicht direkt ins Projekt legt

oder irgendwo nach Opt oder ich weiß nicht.

Ja, also man kann...

Häufig einfach den Default benutzt.

Mhm.

Also ich mache, ist unterschiedlich.

Für Entwicklungen lege ich die ganzen Virtual Envs

in ein Verzeichnis,

damit ich halt nur bei einem Verzeichnis sagen muss,

dieses Verzeichnis bitte nicht backuppen.

Ansonsten müsste ich eine Regel haben,

die das halt für alle,

die halt immer rausfindet,

was ist das Virtual Env in einem Projekt

und dann das dann halt nicht backupt.

Was auch geht, aber ist halt komplizierter.

Und wenn ich mich dann an diese Regel selber mal nicht halte,

dann wird halt ein Virtual Env gebackupt,

was halt doof ist.

Ja, also ich habe aber tatsächlich schon gesehen,

dass tatsächlich sogar die WEMFs Teil der Version Control sind.

Ja, das ist natürlich...

Nee, also das würde ich auch nicht machen,

aber das habe ich schon gefunden,

weil die Leute halt irgendwie die brauchen,

reproduzierbar auch irgendwie auf ihren Systemen,

dann halt tatsächlich einfach die WEMF auschecken

und dann haben sie die schon,

ohne dass sie diesen ganzen Hustle machen müssen.

Oder die wird halt irgendwie gesippt und halt dazugelegt,

weil man die dann für alte Versionen

halt einfach dann dabei hat und die funktioniert direkt.

Und wenn man dann halt jetzt nicht den Python nur gelinkt hat,

sondern das halt als hart dahingeschrieben hat,

dann könnte das sogar funktionieren.

Also...

Ich habe Zweifel.

Ja, gut, aber das ist halt wieder genau so ein Punkt,

wo wir halt merken,

es gibt halt ganz, ganz viele verschiedene Lösungen

für dieses Problem,

wie laufe ich denn überhaupt eine Python an,

die alle nicht so richtig gut funktionieren und so.

Ja.

Alle Probleme haben an irgendwelchen Edge Cases.

Also es gibt, das ist tatsächlich,

also das Beispiel Rust ist da, glaube ich, echt ein guter.

Also weil du machst Rust ab und hast dann Cargo und sowas.

Ja, aber man kann halt,

das wird ja dann auch oft vorgeschlagen.

Warum machen wir es nicht einfach wie Rust jetzt sozusagen

in der Python-Welt und dann sind wir dieses Problem los.

Das funktioniert halt nicht, weil Python halt so alt ist

und es so viele Dinge gibt.

Also tatsächlich größere Teile des Ökosystems würden,

wenn du sagst, okay, das ist jetzt der Weg,

wie wir das machen, halt einfach nicht mehr funktionieren.

Und dann kannst du es halt eigentlich auch nicht machen.

Also einen Plan verpassen.

Also zum Beispiel den ZRPY-Support einstellen.

Das haben auch Leute schon angedacht oder probiert.

Und dann...

Bei den Diskussionen kamen wir raus,

nee, das ist unmöglich, das geht nicht.

Kann man nicht machen.

Also bei Python 4 dann.

Selbe Problem, ja.

Das will auch keiner mehr machen.

Das will auch keiner machen.

Das ist so ein harter, solche harten Kompetibilitäten.

Das wird nicht mehr passieren, glaube ich.

Ja, es ist, aber genau.

Also auf Produktivgeschichten, da mache ich das so,

dass ich das Virtual Env in das Projekt selber mit reinlege.

Einfach deswegen, weil ich dann sozusagen alles an einem Platz habe

und halt auch, wenn ich es dann entferne,

auch nur ein Verzeichnis entfernen muss.

Und nicht noch gucken muss, oh, da gibt es noch das Virtual Env.

Oh, da gibt es ja noch die Datenbank unter Auer.

Da gibt es noch dieses Dings, was ich auch noch mit entferne.

Sondern dann entferne ich das eine Ding und dann fertig.

Ja, also ich habe das tatsächlich unter Opt.

Und dann halt die Python-Sachen alle da an einer Stelle,

die für das Projekt da sind.

Okay, auch interessant, ja.

Und dann habe ich halt quasi das Projekt,

also den Code vom Projekt und den Code von dem,

was für das Projekt zum Lauf notwendig ist.

Also zwei Sachen, aber ja.

Ja.

Ich habe gerade noch daran gedacht,

Hedge zum Beispiel ist eins der Tools,

die ich recht häufig benutze.

Einfach auch nur, weil ich,

weil ich irgendwann damit angefangen habe

und das ganz nett finde.

Und das hat so ein tolles Feature für die Virtual Environments,

dass man im PyProject.toml-File eben auch definieren kann,

deklarativ, welche verschiedenen Virtual Environments

man haben möchte.

Und ich habe beispielsweise häufig eins für Styling,

also wo man, was dann Black über alle Sachen laufen lässt,

wo dann, also da sind da die Dependencies nur,

wie Black, Rough und Ähnliches installiert.

Und auch die Skripte dafür.

Und dann habe ich ein Virtual Environment

für die Documentation.

Ich benutze zum Beispiel Material for mkDocs,

wo das dann installiert ist.

Und dann kann man halt wirklich ganz strukturiert sagen,

okay, diese verschiedenen, ja, Anwendungsfälle

oder das mache ich in meinem Workflow

und dafür brauche ich nur diese Dependencies.

Und dann kann man das wirklich schön organisiert runterschreiben,

PyProject.toml.

Das finde ich irgendwie total angenehm,

weil das so viel besser nach außen kommuniziert.

Potpourri hat das auch irgendwann eingeführt als Groups.

Ah, okay.

Und tatsächlich, also du kannst halt die Gruppen optional machen halt

oder halt nicht.

Also die nicht optionalen Gruppen sind halt die,

die absolut notwendig sind damit,

wie die Anwendung läuft.

Und halt solche Sachen wie Docs oder wie Tests oder sowas

können halt eigene Gruppen haben.

Da hatten wir mal mit Johannes drüber gesprochen.

Johannes meinte, totaler Quatsch.

Du brauchst eigentlich nur zwei.

Und das ist Def und Prot.

Def und Prot, ja.

Kann man auch vertreten.

Ja, aber es ist halt die Frage,

braucht man so einen Fall, wo man nur linden will

oder wo man nur Docs angucken will oder so.

Ja, also mein Argument dafür wäre halt auch genau,

weil ich habe, also oft hat man dann implizit ja doch mehrere.

Zum Beispiel, wenn man sowas wie Precommit Hooks verwendet.

Bei Precommit kümmert sich ja auch wieder selber

da drum.

Und dann hast du es aber implizit irgendwie.

Und es wäre natürlich vielleicht schöner,

das explizit irgendwo stehen zu haben,

wo das, ja.

Ja, Precommit MyPi ist zum Beispiel so ein Kandidat,

der unheimlich nervig ist, weil das halt, ja.

Genau.

Also,

also genau,

also ich würde sagen,

wenn man nur Def und Prot haben will,

dann schafft man das nicht,

weil man hat ja zumindest noch das für Precommit.

Und das heißt,

dann hat man nochmal einen Ort, wo man das pflegen muss.

Das steht ja auch nicht in der PyProject Tommel,

sondern es steht dann auch wieder in dem Precommit Jammel.

Und, äh, Jammel, Uwe.

Das ist sehr mäßig.

Bei mir sind es halt so Gruppen, die sind alle optional,

die ich alle per Default dann wieder copy und paste.

Wo halt dann sowas drin ist,

wenn eine Postquest benutzt wird,

dann mach doch bitte diese Gruppe noch dazu.

Und wenn irgendwie Authentifizierung benötigt wird,

dann mach doch bitte diese Gruppe noch dazu.

Und wenn, ja, so Dokumentationen,

dann muss halt alle die...

Okay, an der Stelle würde ich sagen,

beschränk dich doch bitte auf Def und Prot.

Kann man denn bei den Gruppen in Poetry

dann auch Skripte für diese Gruppen,

definieren?

Ähm, nicht, dass ich wüsste.

Aber vielleicht vertue ich mich auch alle.

Ja, also Poetry hat eh immer so ein bisschen so Probleme

mit so dann Sachen wieder abreißen oder sowas.

Oder wenn du halt irgendwie ein Update

von einem Major Python machst,

dann fliegt Poetry oft auf die Nase.

Das ist halt fürchterlich.

Vielleicht ist das jetzt neu besser.

Also auch so ein Ding, ne?

Poetry hat irgendwie zweimal ein Update gemacht,

das so Breaking Changes eingebaut hat,

wo es dann...

Das war halt so sehr, sehr nervig.

Wirklich böse Dinge gemacht hat.

Ja, das war halt der Hauptgrund,

warum viele Leute gesagt haben,

so eine Idee fasse ich jetzt nicht mehr an,

weil sowas geht halt eigentlich nicht, ne?

Genau, ja.

Das habe ich auch total viel mitbekommen.

Also ich habe selbst schon Poetry benutzt.

Das hat für mich immer gut funktioniert

und ich finde es auch ein gutes Tool.

Aber ich habe voll viele Leute,

von voll vielen Leuten das mitbekommen,

die dann einen dieser Breaking Changes mitgemacht haben

und dann gesagt haben, nie wieder.

Also kategorisch benutze ich nicht mehr.

Sowas geht nicht.

Das kann man nicht machen.

Und dann hat man eben auch genug Alternativen,

auf die man zurückgreifen kann,

sodass man Poetry dann nicht mehr verwenden muss.

Also ich sage mal so,

andererseits, das waren halt so ein paar Sachen echt kaputt

und die haben die jetzt gefixt.

So gesehen, ne?

Wenn man jetzt einmal diesen Schmerz hat

und es läuft dann jetzt wieder, warum dann nicht?

Aber ja, ich weiß nicht.

Ich glaube, es war bei vielen auch diese Art und Weise,

mit der es gemacht wurde,

dass zum Beispiel nicht gewarnt wurde davor,

dass bestimmte Dinge dann nicht mehr funktionieren werden.

Ja, ich glaube, der Ton in den Requests

oder in den Issues war auch so ein bisschen rau.

Habe ich das Gefühl gehabt.

Das war, einige Leute fanden das auch nicht so gut.

Poetry ist halt auch so ein Sonderfall,

habe ich manchmal das Gefühl.

Also ich hatte mir so ein paar Kriterien rausgesucht,

um die verschiedenen Tools zu vergleichen,

damit es eben wirklich so ein bisschen unbiased ist

und nicht nur meine persönliche Präferenz mit reinfließt.

Und es gibt ein PEP 621, da geht es darum,

wie man Metadata in der PyProject-Hommel aufschreibt.

Also in welchem Weg.

Und da wurde halt irgendwann ein Standard definiert,

den die meisten Tools vertreten.

Nur Poetry hat da seine Extrawurst und macht das anders,

was ja auch in Ordnung ist,

dadurch, dass sie es von Anfang an anders gemacht haben.

Aber es gibt, glaube ich, seit eineinhalb Jahren

schon ein offenes Issue dazu auf GitHub

und sie wollen es auch irgendwann machen.

Aber sie haben es halt immer noch nicht gemacht.

Und ich glaube, so ein paar Besonderheiten

muss man da schon im Kopf behalten,

wenn man dann Poetry benutzen will.

Ja, also das war auch,

als ich dann irgendwie auch Probleme mit Poetry mal bekommen habe

und dann halt da auch angefangen habe,

Issues aufzumachen und dann mir das Open Issues-Ding mal angeguckt habe,

da dachte ich so, oh, oh, oh.

Also letztlich, glaube ich, ist das einer,

der auch eigentlich als Freelancer arbeitet,

der das halt auch nicht Vollzeit macht,

sondern halt auch so in seiner Freizeit.

Und zu dem Zeitpunkt, wie es heute ist, weiß ich nicht.

Und da waren halt tausend offene,

offene Issues in dem Projekt.

Das ist halt so, okay.

Und einige schon sehr, sehr lange offen.

Und ja, na ja.

Ich meine, es ist ja klar,

dass man das nicht so hinkriegen kann.

Gerade wenn das dann halt viel verwendet wird,

dann wird man halt erschlagen von dem Ansturm von Leuten,

die irgendwas ändern wollen oder irgendwelche Probleme gefunden haben.

Aber ja.

Ist halt für Leute, die das halt noch ein Problem haben.

Ja, das ist ein Open Source Schicksal so ein bisschen.

Ja, ja, natürlich.

Also es, ja, ja.

Wo würdest du denn den Unterschied sehen zu,

zu, zu, zu Hedge oder, oder Rye?

Kann man das irgendwie kategorisieren,

wo da die Unterschiede liegen?

Also ich habe es so ein bisschen kategorisiert

aufgrund der Dinge, die sie tun können.

Beispielsweise ist Rye somit das einzige Tool,

was wirklich alles kann.

Eben auch Python Version Management.

Dadurch, dass es eben nicht in Python geschrieben ist,

sondern in Rust.

Und man dann eben alles in einem Tool machen kann.

Ja, auch so Project Scatboarding oder sowas

mit fürchterlich opinionated und dann so.

Na ja, sorry.

Kein Problem.

Genau, und da gibt es PDM, Poetry, Hedge,

die noch mal so ein bisschen rausfallen,

weil sie, also PDM und Poetry zum Beispiel,

können kein Python Version Management machen.

Man kann einfach PyEnv benutzen,

aber die haben das nicht als eigene Funktionalität drin.

Also dass man irgendwie sagen kann Poetry, keine Ahnung,

add Python Version irgendwas.

Aber sowas gibt es nicht.

Und Hedge wiederum, das ist noch,

also wird auch natürlich sehr aktiv entwickelt.

Aber das kann zum Beispiel,

also jetzt gerade hat es noch keine Package Management Möglichkeiten.

Also man kann jetzt nicht wie bei Poetry,

da kann man ja sagen Poetry add irgendein Paket

und dann fügt Poetry das in die PyProject Tommelfile hinzu

und macht auch, versucht die Dependency-Konflikte zu lösen.

Und das kann Hedge noch nicht.

Der hat immer angekündigt, dass er das noch implementieren wird.

Aber bisher ist es noch nicht da.

Es sei denn, das wurde jetzt die letzten Tage hinzugefügt.

Ich habe es noch nicht gesehen.

Genau, ich glaube, das kommt so,

ein bisschen auf den Use Case drauf an.

Flit hatten wir auch schon besprochen.

Flit ist halt eben wirklich dazu gedacht,

wenn man einfach nur ein Package bilden und publishen möchte

und vor allem ein Package, was keinen C-Code hat oder ähnliches,

sondern wirklich nur Python-Code.

Ich glaube, das ist ganz gut, wenn man sich vorher mal überlegt,

was möchte ich überhaupt machen und dann dementsprechend

sich das Tool raussucht.

Ich muss aber auch sagen, dass bei diesen ganzen Tools

letztlich die persönliche Präferenz und was das Team macht,

auch eine riesengroße Rolle spielt.

Wenn jetzt alle im Team Poetry benutzen,

wird es wahrscheinlich schwierig, Hedge zu benutzen,

weil in der pipe-project.toml-File eben auch das Build-Backend

definiert ist und da steht dann eben Poetry drin.

Vielleicht noch mal ganz kurz zu dem Packaging.

Also ihr wollt ein Paket auf PyPI veröffentlichen.

Das ist so das, was dahinter steht.

Du meinst mit dem Publishen gerade?

Ja.

Ja, genau. Stimmt.

Das kann man vielleicht noch einmal kurz erklären,

dass man bei Packaging zwei verschiedene Schritte dann hat.

Also man kann den Build-Schritt machen.

Das bedeutet, dass ein wheel-File erstellt wird,

was so das Format ist, mit dem das Package beschrieben wird.

Und da ist dann wirklich auch alles drin, was das Package braucht.

Das ist auch letztlich das, was von PyPI gezogen wird,

wenn man pip install was auch immer macht.

Und es wird ein tarball-File erstellt, so .tar.gz.

Und der Publish-Step ist dann,

dass man diese Dateien zu PyPI oder zu irgendeinem anderen Index

veröffentlicht, was man ja gar nicht unbedingt machen möchte.

Manchmal reicht es auch schon, wenn man ein wheel-File erstellt,

was man dann lokal hat, was andere installieren können.

Für Wheels vielleicht noch.

Bei Windows gibt es Goalke, eine wundervolle Bibliothek

von gut gepatchten Wheels für Pakete,

die man sonst bei Windows nicht einfach so installieren kann,

weil man die irgendwie selber kompilieren müsste,

wo dann Kompilierungs-Tools-Probleme auftauchen können oder die es nicht gibt.

Aber auf Windows geht es immer.

Also super tolle Quelle.

Ich merke schon, wenn ich irgendwann mal doch Windows benutzen muss,

dann werde ich auf dich zukommen.

Du hast alle Hexen, die man so braucht.

Ja, das ist einfach so viel Quatsch, die man irgendwann gegenfaut.

Irgendwann geht es dann vielleicht, ja.

Letztens hat jemand einen ganz alten Webcomic repostet

auf Mastodon von 2004 oder so.

Ich weiß nicht, welcher Webcomic das jetzt war.

Man sieht halt irgendwie so Star-Trek-Setting

und im Hintergrund irgendwie Klingonen sich mit so Schmerzstöcken quälen

und einem vor dem Grund sagen so,

oh, ich habe was noch viel, viel Härteres gefunden als Schmerzstöcke.

Irgendwie ist dann hier einfach Windows auf meinem Laptop.

Obwohl man tatsächlich dazu sagen muss, ja,

also mit den neuesten Power-Shades und den neuesten Windows-Terminals

und wenn man das so ein bisschen beherrscht,

kann man auch ohne VSA einigermaßen gut entwickeln.

Es gibt halt so ein paar Sachen, die gibt es noch nicht als Pakete.

Aber für die meisten Sachen geht es ordentlich.

Und mittlerweile würde ich jetzt behaupten, auch für Windows.

Du kennst dich damit sicherlich gut aus.

Ja, ich muss halt damit die ganze Zeit arbeiten.

Also ich würde es auch jetzt nicht unbedingt immer machen wollen,

aber es geht irgendwie schon.

Also ich brauche keinen Docker mehr, wie es vorher die ganze Zeit war.

Dann muss man halt einfach Docker installieren und dann hält das laufend.

Ja, mit Docker geht es natürlich.

Aber auch da hast du natürlich Probleme.

Genau, ja.

Und das wird nach einer Zeit alles ein bisschen langsamer und hässlich.

Aber es geht auch mittlerweile relativ vieles

oder eigentlich alles nativ direkt mit Ausnahmen.

Es gibt so ein paar Pakete, die laufen.

Ansible zum Beispiel.

Zickt halt rum, muss halt doch ein Docker laufen oder auf ESL oder sowas.

Ich habe gerade noch gedacht, mit der Frage von gerade,

mit den verschiedenen Tools, was, finde ich, auch eine große Rolle spielt,

ist, in welchem Entwicklungsstadium die sich befinden,

beziehungsweise wie aktiv die weiterentwickelt werden.

Weil Rai zum Beispiel ist ja ein sehr junges Tool.

Das ist erst, glaube ich, im Mai rausgekommen

und ist auch eigentlich entstanden mehr so als Spielerei, würde ich mal sagen.

Er hat jetzt nicht gedacht, der Auto, dass das jetzt ein Tool wird,

was total viel läuft.

Dass das für viele Leute genutzt wird.

Das nutzen aber voll viele Leute.

Also Rust jetzt hat ja, also Armin Gronacher ist wahrscheinlich der Typ,

der hat Flask gemacht, ne?

Ja, ganz viele, ganz viele Projekte.

Jochen weiß da mehr.

Aber ja, also er macht jetzt gar keinen Python mehr hauptsächlich,

wenn ich das richtig verstehe.

Aber er benutzt halt Python noch manchmal.

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

die tatsächlich so ein bisschen nach dem aussieht,

was sich eigentlich die meisten Leute so wünschen.

Aber ja, also ich habe es auch so ein bisschen ausprobiert

und dachte mir so, na, nicht ganz das, was ich brauche.

Was hat dir denn gefehlt, oder?

Also der Stil, wie.

Also vor allem das Project Scaffolding

und wo die Sachen dann liegen und so.

Das ist halt alles opinionated.

Ich meine, ist halt, sein gutes Recht,

er macht halt sein Kram, ist ja voll super für ihn,

aber nicht das, was ich machen würde.

Ich hätte das gerne konfigurierbarer oder so.

Und würde halt das gerne auf meinen Stil umbringen.

Ja.

Ich glaube, das muss man halt auch so ein bisschen im Kopf behalten,

wenn man jetzt sagt, okay, wir benutzen Rai