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, sorry, was dazwischen gekommen ist.
Wir haben uns auch schon viele Leute geschrieben.
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 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 sehr unterschiedlich, was man da für
Kundenprojekte hat.
Ja, 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
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 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. Das sagst du Jochen 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.
Und das Ganze...
Also ich würde auch sagen, das ist so das Hauptproblem, wenn ich
auch einen Neuling oder sowas versuche, Python
beizubringen oder 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.
Nicht nur ein bisschen, sondern sogar ziemlich nervig.
Ja, ich bin ja auch
tatsächlich da auf deine Meinung sehr gespannt
hinterher, auf deine persönliche Präferenz, was du
sagst, was am besten funktioniert.
Aber ich finde es cool, dass wir diese
und PyTest.
also seit letztem Mal
PyDentic Version 2
ist raus, 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 Extralibrary jetzt mit drin ist
direkt in PyDentic selbst
Ja, genau
Das heißt jetzt auch schnell
Das ist jetzt...
und es gibt jetzt eine Firma hinter PyDentic und die hat auch irgendwie, glaube ich, von Sequoia oder so ordentlich Venture-Craft-Weltbekommen.
Das habt ihr, glaube ich, erwähnt in der letzten Episode.
Hatten wir schon erwähnt, achso gut.
Habt ihr schon erwähnt, ja.
Okay, 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 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.
oder halt halt irgendwie, früher war es halt so,
dass wenn man bei einer
bei so einem Feld
gesagt hat, typing any,
dann war das defaultmäßig none.
Und
das ist es jetzt nicht mehr.
Jetzt kriegt man einen Fehler und das
sagt halt irgendwie, du hast da
einen Wert nicht gesetzt.
Und dann runterkommen aber die
anderen Variablen und dann hatte ich das irgendwie falsch
einsortiert und bin dann irgendwie falsch
abgebogen. Dann musste ich halt irgendwie, weil
es hat sich ja noch ganz viel anderes 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.
Ja, das war schon, dachte ich so, ja.
Aber im Grunde ist das natürlich eine tolle Sache, dass das jetzt irgendwie alles auch schnell funktioniert und so.
Ja, aber ich werde wahrscheinlich noch ein bisschen brauchen, bis ich alle Sachen, die ich bei der Intake verwende, da umgezogen habe.
Benutzt du 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 Django REST-Framework geht
Genau, ich wollte gerade sagen, das ist kein Django REST-Framework
Doch, also für
so REST-APIs nehme ich normalerweise Django REST-Framework
aber manchmal kommen Daten ja auch
von woanders und dann
nehme ich schon ein paar Identik
Aber da gab es ja auch ein paar News von, ich glaube REST-Framework wird irgendwann
duplicated und nach Django reinwandern
irgendwie jetzt mit 5 sogar schon
Ja, das weiß ich noch nicht
also die Kerngeschichten
wandern in
in Django selber rein
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 auch so riesig
Ja, vielleicht aber natürlich keine Sache, ne?
Also man bräuchte es wahrscheinlich dann gar nicht mehr, wenn man nur so einfach
eine Sache macht.
Genau, das ist halt, ja.
Insbesondere wenn man dann diese PyTentic-Validation macht oder sowas, 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, ich finde 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.
Ja.
Da haben wir 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, das will ich mir unbedingt angucken, hab es 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 Dinge machen kann
das kann man halt super feintunen
gerade die kleineren Modelle kann man super feintunen
auf irgendwelche Probleme 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
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.
Daher, ja.
Hab ich mir auch schon gedacht,
ich würde gern
Naja
Weißt du, was ich rausgefunden habe, wofür man LLMs noch wunderbar benutzen kann, wo ich sehr überrascht war?
Ne, sag mal
Musiktipps
Musiktipps?
Ja, das fand ich hervorragend
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ö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, aber klingt gut
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.
Ach, witzig.
Ich dachte gerade, du hättest den gehört.
Nein, habe ich tatsächlich nicht gesehen.
Sonst hätte ich den auch jetzt empfohlen.
Aber den habe ich tatsächlich verpasst.
Die sind jetzt alle auf YouTube seit einer Woche, glaube ich.
Ah, gut.
Okay, also auch noch, das muss auf jeden Fall auch nicht shownoten.
Dann können wir nochmal die Europython-Talks verlinken.
Ja.
Genau, ansonsten, ja.
Ja, Postgres 16 ist raus, ist jetzt zwar nicht so wirklich was mit Python zu tun, aber vielleicht, die meisten Leute dürften ja auch irgendwie den 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 der PG-Upgrade einfach drüber laufen lässt, das hat einfach immer so funktioniert, auch mit 14, also es war ein sehr problemloses Update für mich.
und hat auch
eine Menge nette Sachen drin.
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 springt
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, wieder
sich das alles anzulesen, noch
und PyTest.
erwiesen haben, sich das dann nochmal anzugucken.
Ich weiß es nicht.
Schwierig.
Ja.
Ja gut, aber ansonsten.
Ja, meine News sind alle gerade nicht so technisch
da, deswegen skippen wir die für heute einfach mal.
Okay.
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?
Hätte ich auch gesagt, ja.
Okay.
Wollt ihr auch über das Python
Version Management reden? Das hatte ich auch als
Kategorie noch aufgenommen. Ja, also Fintech gehört auch
dazu und das überschneidet sich ja teilweise auch, weil auch
PyEnv ja 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 das ist jetzt einigermaßen
nutzbar, aber es hat halt nicht so schöne Sachen auch drin,
wie Minikonda 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ß nicht, vielleicht, ich fange ja auch
an mit PyEnv, also ich würde tatsächlich PyEnv
installieren und dann mit PyEnv die
Python-Version installieren, die das
vorhin 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 aufgeschaltet
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
beschäftigt habe, ob es Kategorien gibt
weil bei Python
gibt es eben unheimlich viele Tools, die alle
verschiedene Dinge können und die 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, dass das
wirklich macht. Viele
die das, also zum Beispiel
Rye ist so ein Multipurpose-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.
Es gibt 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, also ich brauche es auch genau lokal, wenn ich 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 ein Virtual Env
mit einer bestimmten Python-Version
haben möchte, dann ist halt PyEnv genau das, was man
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
Env, 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 PyEnf 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-Versionen 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 denke, oh nein, da brauchst du
eigentlich Minikon da und irgendwie ein Virtual
App oder so.
Das ist ein Einstiegspunkt, weil das halt auch
in der Data-Science-Welt irgendwie sehr empfohlen wird als
Entry-Point.
Kann man mit Py einfach 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
und PyTest.
Wenn wir 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 Envs verwenden den gleichen Interpreter,
die halt mit dem gleichen Interpreter
erzeugt worden sind.
Ein Virtual Env ist tatsächlich 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, 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,
und 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
dem 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
Ja, das ist ja auch ein Bild, Python-MV
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
deswegen ist das auch bei Data Science immer so
das braucht man halt einfach
häufig hat man halt nicht so
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 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, 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 mit
Pip nicht gehen. Ja, da sind wir schon recht drin,
es gibt ja Pip, was macht Pip?
Pakete von PyPI 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 man häufiger nutzt, oder?
Noch eine Isolationsschicht
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 nicht dabei einliegen und teilweise
Binary-Stil, die du halt direkt da beziehen kannst.
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
Mini-Konda eigentlich immer eine gute Variante,
was mit Python kommt, schon mit
einer Version und eben mit
Konda, mit dem Package-Manager, sodass man die
Pakete dann installieren kann, die aber
von dem Konda-Index
kommen, dann nicht von PyPI.
Ja, also ich denke,
wenn man jetzt halt noch härter isolieren will als
mit Konda, dann wäre
halt Docker das Ding, was man
noch verwenden kann, was halt viele benutzen.
Ja.
Ja, das ist ja so langsam
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
Ja, muss man beeilen
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 sie eigentlich denken, was laufen
sollte und sowas
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 Conda, 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 hat alles so
seine Tücken.
Ja, es ist leider kompliziert.
Ich weiß auch nicht,
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 hat, das kann man
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 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, der
gibt es immer große Widerstände,
wenn man sich auf einen 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 wirklich sehr auf die Kunden
zu achten.
Ja, solange alle Leute das so machen, wie ich das richtig halte,
ist das natürlich so.
Ja.
Genau, wo waren wir denn
überhaupt?
Wir haben Python installiert
und wollen jetzt halt ein Environment haben und dann
gibt es halt verschiedene Sachen, wie man das macht.
Also was ich gerne noch zu Python
sagen würde, also ich benutze das halt
für Entwicklungsmaschinen, wenn 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 PyTest verwendet um halt dann auf Produktivmaschinen eine Python 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. Ich dachte so,
nee, das kann nicht sein. Doch,
ist aber so. Also, das ist tatsächlich die
von mir momentan präferierte
auf ein Produktivsystem zu installieren, ist halt
selber zu kompilieren und
auf der Ausgabe zu bauen.
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-Candidates oder so, das ist immer sehr nett dafür.
Genau.
Ich überlege gerade, wie das so gut 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 Verhalten-Version verwendet haben
wo ich das
gar nicht mehr gedacht hätte, dass sie das tun
und es aber alles weiter funktioniert hat
und ich das aber gar nicht wollte
und dann gesagt, also
ist es mir doch lieber, dass halt, weil ich
und ich hätte sowieso gerne immer die gleichen Python-Versionen für alle.
Aber den Fall, dass ich das unterscheiden würde, den habe ich gar nicht.
Aber es kann ja mal sein, dass du irgendwie so eine harte obere Schranke hast,
weil irgendein Projekt auf irgendeine völlig veraltete Library dependet,
die halt schade ist, aber die halt da irgendwie erst drin hängt
und jetzt musst du halt eine alte Version nehmen.
Ja, passiert bei meinen Sachen nie.
Okay, ja, okay.
Also ich habe schon ein paar Kunden, geht das so?
Ja, klar.
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, wie der
Hustle ist, muss ich das alles selber konfigurieren.
Das ist ja genau das, warum ich ja solche Tools
nutzen möchte. Ja, siehst du, kommt drauf an.
Ja.
Ja, leider.
Tja, ja.
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,
und das zu lösen irgendwie, ne?
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
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 ist für Rust am Machen,
dass so seine Opinion ist, wie man so Projekte
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 sowas, 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 brauchen wir 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 erstellt,
erstellen wollte,
wenn benutzt oder Virtual Env, um das
schnell machen zu können. Also ich benutze
dann immer noch Virtual Env Wrapper,
weil das halt dann irgendwie nur so drei oder
vier... Ja, da gibt es dann auch ein paar interessante
Shell-Aliasse, die man dann... Genau.
Ehrlicherweise auf Windows,
wenn ich Windows benutze, das ist ja immer Quatsch, da gab es irgendwie
Virtual Env Wrapper PowerShell, das irgendwie fürchterlich war und ich habe es
einfach selber geschrieben, was eigentlich nur ein Wrapper
um Benf ist. 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
ja auch machen.
Ja, nein, also ich benutze
es nicht mehr.
Ich habe es noch nie benutzt dafür.
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
habe, die Shell.
Und jetzt verwende ich halt zum Verwalten der Virtual
Apps Virtual Fisch, was ich auch noch
spielen kann, wenn man die Fisch-Shell 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 wird eine große Diskussion 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 Venv-Kurse brauche, dann einfach mit dem
Virtual Env-Rapper, 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.toml-File
rumfliegen hat und überhaupt nicht weiß,
was das macht und wofür man das braucht.
Da kann es schon ganz hilfreich sein, einfach mal nur diese
Tools zu benutzen, wie VENV.
Ja, über die PyProject.toml
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 wie Poetry zum Beispiel 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,
das sagt der Name ja auch schon, dass es Pip
und Virtual Env zusammenführt
und das Ganze noch mal
ein bisschen mehr abstrahiert, also
noch mehr Funktionalitäten hat und man darüber
auch Packages installieren kann.
PipEnv höre ich immer relativ komische Dinge.
Weiß ich nicht.
Inwiefern?
Ja, also früher, also 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. Das ist nicht mehr so. Das ist inzwischen, weil es halt auch eins von den Projekten von, na, wie heißt der noch? Kenneth Wright. Ursprünglich, aber der hat damit glaube ich nichts mehr zu tun.
Also, das ist abgegeben.
Ich glaube, das war mir zu einer der Gründe, wo man gesagt hat,
aber, ja,
wenn das jetzt in anderen Händen liegt,
müsste man das nochmal angucken.
Ja, okay, hat auch noch so eine...
Ich glaube es aber, ja, ganz viel
in diesem Bereich, da kommt es aber auch
drauf 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 Pipens 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.toml-Files,
dass man die benutzt und die haben eben auch so
einen eigenen Weg, das zu machen.
Also wenn man PipEnv benutzt,
hat man plötzlich ein 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 PyPen
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 habe es jetzt noch nie in einem Projekt
benutzt, also in einem Kundenprojekt. Ich habe es mal
selbst ausprobiert. Darum kann ich da nicht
und Python-Tools.
und PyTest.
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
na, so richtig
so, leider sind die Sachen doch sehr
so unterschiedlich, dass man sich dann doch
dafür interessieren muss, dass diese Abstraktion halt anfängt
zu nicken und dann
dann wird es halt hässlich
Also ich finde Poetry
Super, weil es halt drei Sachen für mich macht.
Und das sind 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 ich es 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, weil das ist nämlich genau der Punkt, wo ich wahrscheinlich
weiß ich nicht, ob ich Portree-Filmen nehmen würde.
Ich habe ja irgendwie Flit oder Hedge 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 hingeployt
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 Pochi
macht da Ding, äh, da
hat mich sozusagen
kalt erwischt, dass
die, dass das halt zwei
sehr unterschiedliche Use Cases sind und ich dachte, ich könnte das halt für beides gleich verwenden.
Dann will man halt irgendwie den Pfad für Poetry Home setzen
und dann installiert es aber trotzdem irgendwo anders andere Dinge hin und sowas.
Das ist halt einfach total nervig.
Das Schlimmste war, 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 hindeployt,
eine obere Schranke für
Abhängigkeiten hat. Das kannst du aber einstellen.
Klar kann man das einstellen, ich habe es 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 dein
Paket als Abhängigkeit haben, halt total blöd.
Ja, also obere Schranken, also da war ich
erst anderer Meinung und das macht
im Datastore-Umfeld unheimlich viele Pakete,
die halt obere Schranken drin haben.
Und es gab diesen sehr länglichen Blogpost
dazu, den du mir geschickt hast,
den wir auch nochmal verlinken können, der
mich auch überzeugt hat zu sagen, dass das wahrscheinlich
eine ziemlich doofe Idee überhaupt, so eine obere
Schranke zu haben.
Interessant, das ist mir noch nie begegnet,
das Problem.
Ja, 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 würde es 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 irgendwelchen
Third-Party-Geschichten, also man hat halt irgendwie
eine Krypto-Library
oder so, die man halt
als Einbringlichkeit verwendet, weil man irgendwas
für irgendwas braucht
und dann
sozusagen hat man eine implizite
obere Schranke auf der
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 und kann
es nicht mehr installieren. Und das gar nicht
deswegen, weil es einen echten Konflikt gibt, sondern deswegen, weil
ich einfach nur in der Default-Einstellung nichts geändert habe.
Und das ist halt, genau.
Und wenn dann Leute sagen so, dein
Library ist, die macht irgendwie
hier bei mir Dinge kaputt, dann
ja, das ist halt nicht so schön. Genau, und das ist 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 es da geht, 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, besteht auch mit dem, damit.
Also, apropos
Tools, Jochen, du mit 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 wenn ich halt auch sowas wie Blog-Files
bei meiner Library habe, habe ich ja keinen
Logfile. Aber bei einer Applikation
hätte ich natürlich schon wieder einen Logfile, sodass halt alle
Entwickler irgendwie das halt weiß.
Was nochmal ein Logfile ist,
also ein Logfile ist
normalerweise, pinnt halt die Dependencies
und insbesondere den
Subdependency-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
gepinnt sind und
meistens hasht es 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 runter
geladen hat, auch tatsächlich
das ist, was man haben wollte.
Genau.
Also es führt halt dazu, dass wenn zwei Leute
sozusagen
das Virtual Env mit
allen Environments
installieren,
kriegen sie genau das gleiche und haben nicht
unterschiedliche Versionen von Paketen.
Das Hauptproblem auch, also klassisch ist ja
Requirements.txt. Genau, da wäre es
nicht so. Da sind halt diese ganzen Subdependencies
nicht enthalten. Es kann halt sein, dass wenn man
Requirements.txt irgendwie ein Jahr später installiert,
und wie das dann gebrochen ist, weil sich da Anhängigkeiten geändert haben.
Man erzeugt die Requirements.txt, sechs Monate später kommt ein Entwickler dazu und installiert nochmal und sagt,
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 Blogfiles halt.
Und deswegen, also diese Blogfiles sollten eigentlich meiner Meinung nach auf jeden Fall Teil von so einem Projekt 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 PipTools 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 Flit4Dig 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 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
Will-File braucht und das vielleicht dann noch publishen will
und wenn das für einen selbst funktioniert, dann
wunderbar, dann kann man das wirklich gut
verwenden. Ich habe gerade noch daran gedacht, mit
den Log-Files, was ihr gesagt hattet, mit
und wie man das mit dem Unterschied zwischen abstrakten und konkreten Abhängigkeiten,
das kann man vielleicht auch nochmal ganz gut in Verbindung mit dem PyProject-Hommelfile erklären,
weil wenn man ein Paket baut, hat man eben PyProject-Hommelfile,
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 in dieses PyProject.
Also die ganze Konfiguration löst halt diese
PlayStore an Konfigurationsfiles ab, die dann irgendwo
im Projekt-Root rumfliegen müssen.
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 auf genau
die Version pinnen, die man haben möchte,
wofür dann die meisten Tools eben automatisiert
so ein Logfile erstellen, wie ihr das gerade
beschrieben habt, sodass man das
auch noch mitgeben kann in sein
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 SetupPy
gemacht und SetupTools
und 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,
gibt auch noch Disk-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
hingeschrieben haben, halt kopiert und
aber, 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
ein
Es ist auch eben überraschend,
finde ich, also ich habe gerade mal
das PEP geöffnet von
518, wo es
darum geht, dass PyProject.toml 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.toml-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 ja 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 PyProject Tommel 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 PyProjektumme
zu nehmen, also Flake.
Flake 8 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 einen 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,
um 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 Kundenprojekt wieder, dass jemand
Mac-File benutzen wollte, um
bestimmte Kommandos,
die man häufig ausführt,
runterzuschreiben oder zu vereinfachen,
weil der Person gar nicht bewusst war,
dass man das auch im PyProject.toml-File
definieren kann. Also wenn man zum Beispiel immer
Python-minus-m
unit-test-discover-test schreibt,
dass man das einfach abkürzen
kann, indem man in der PyProject.toml
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,
bei mir ist es dann cc,
weil ich habe meinen c-Compiler
die linkt 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
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 Library und
install-e oder sowas,
also editable installiert ist
eine der Features, die nicht jedes
von diesen Tools unterstützt. Ja, da hat
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-import 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,
das 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
Pakete installieren und dann so, welches Paket?
Okay, und dann ist es halt immer noch mal
eine Hürde.
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 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 oder was auch immer Und dann l Hedge dieses Skript innerhalb eines Virtual Environments laufen wo alle diese Dependencies die man im PyProject definiert hat schon installiert sind Sprich man muss das nicht mehr manuell erstellen dieses Virtual Environment Das wird dann f einen gemacht
Ja, dann, also Poetry zum Beispiel, das kann man halt auch dann konfigurieren, dass halt alle Vents in einem bestimmten Ordner liegen, wenn man das gerne hätte.
oder dass sie halt im Projekt liegen.
Also das gibt ja 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 Wemps
vergleichen will oder ob man das halt
ein Prot macht, wo man das vielleicht direkt ins Projekt legt
oder irgendwo nach Opt oder
ich weiß nicht. Häufig einfach
den Default benutzt.
Also es ist unterschiedlich. Für
Entwicklungen lege ich die ganzen Virtual Enders in
ein Verzeichnis, damit ich halt nur
bei einem Verzeichnis lagen 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 VEMs Teil der Version Control
sind. Ja, das ist natürlich,
nee, also das würde ich gar 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 VEMs
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 nicht funktioniert direkt
wenn man dann halt jetzt nicht
also den Python nur gelinkt hat
sondern das halt als hart dahin geschrieben 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 mit Python an
die alle nicht so richtig
gut funktionieren und so.
Alle Probleme
haben an irgendwelchen Edge-Cases.
Das Beispiel Rust ist da glaube ich echt ein gutes.
Du machst Rust ab und hast dann Argo
und sowas.
Das wird ja dann auch oft vorgeschlagen.
Warum machen wir es nicht einfach wie
Rust jetzt sozusagen in der Python-Welt?
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 zum Beispiel den
PySupport einstellen,
das haben auch Leute schon angedacht oder probiert
und dann bei den Diskussionen kamen wir raus,
es ist unmöglich, es geht nicht, kann man nicht machen.
Also wer peistet 4 dann?
Das will auch keiner mehr machen.
Das will auch keiner machen.
Das ist so ein harter, solche harten
Incompetitivitäten, das wird nicht mehr passieren, glaube ich.
Ja, es ist,
aber genau, also auch 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, oh, da gibt es ja noch
die Datenbank, da gibt es noch dieses Ding, was ich auch noch mit
entfernen, 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.
Ich habe gerade noch daran gedacht, Hedge zum Beispiel ist eines 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.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
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
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.
Pulti hat das auch irgendwann eingeführt als Groups.
Und tatsächlich, du kannst halt die Gruppen
optional machen oder halt nicht.
Die nicht-optionalen Gruppen sind halt die absolut notwendigsten,
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 defenbrot.
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 Precommit Hooks verwendet
weil Precommit 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
ja, also
Precommit MyPy ist zum Beispiel so ein Kandidat,
der unheimlich nervig ist, weil das halt...
Ja, genau.
Also
ich würde sagen, wenn man
nur Dev und Pod 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. Es steht ja auch nicht in der PyProject
Tunnel drin, sondern es steht dann auch wieder in
dem Precommit-Jammel.
Das ist unmesslich.
Bei mir sind halt so Gruppen, die sind alle optional,
die ich alle per Default dann wieder copy und paste,
und so weiter.
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 so ein Ding. 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.
Ja, das war halt der Hauptgrund, warum viele Leute gesagt haben,
so ein Ding, die fasse ich jetzt nicht mehr an, weil
sowas geht halt eigentlich nicht. 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
und das ist ein Test, das wir in der Zeit, in der wir in der Zeit, in der wir in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der Zeit, in der
Ja, ich glaube, der Ton in den
Requests und an den Issues
war auch so ein bisschen rau.
Das war, einige Leute
waren das auch nicht so gut.
Poetry ist halt auch so ein Sonderfall, habe ich manchmal das Gefühl.
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 Tommel 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 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
Poetima bekommen habe und dann halt da auch angefangen habe
Issues aufzumachen und dann
mir das Open Issues
Ding mal angeguckt habe, dass ich so
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
und einige schon sehr sehr lange
offen und ja
naja
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
Probleme gefunden haben, aber
ja
ist halt für Leute
ein Problem
Wo würdest du denn den Unterschied sehen zu Hedge
oder Rye?
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, auch so
Project Scatboarding oder sowas, fürchterlich opinionated
und dann so
Sorry.
Kein Problem. Genau, und da gibt es
PDM, Poetry,
Hedge, die nochmal so
und wie man das mit Python umsetzen kann.
in irgendein Paket und dann fügt Poetry das in die PyProject.toml-File 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, 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 einmal ü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 PyProject.toml
Fall eben auch das Build-Backend definiert
ist und da steht
dann eben Poet für drin.
Vielleicht nochmal ganz kurz zu dem Packaging.
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 nochmal einmal kurz erklären,
dass man bei Packaging zwei verschiedene
Schritte dann hat. Also man kann das
und den Bildschritt 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 whale-File erstellt, was
man dann lokal hat, was andere installieren können.
Für wheels vielleicht noch,
bei Windows gibt es Golke,
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.
Es ist einfach so viel Quatsch, wenn man irgendwann mal gegenfährt.
Irgendwann geht es dann vielleicht, ja.
Ich habe
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
Klingonen sich mit so Schmerzstöcken
quälen und im Vordergrund sagt so
Oh, ich habe was noch viel härteres gefunden als
Schmerzstöcke. Ich sitze hier einfach
Windows auf meinem Laptop.
Obwohl man
tatsächlich dazu sagen muss,
also mit den neuesten
PowerShells 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.
FSEvent oder
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 nicht unbedingt immer machen wollen, aber es geht
irgendwie schon.
Also ich brauche kein Docker mehr,
wie es vorher die ganze Zeit war.
Dann musst du halt einfach Docker installieren und dann hältst du auch was.
Ja, mit Docker geht es natürlich, aber auch da hast du
WSL oder so Probleme.
Genau, ja, und das macht halt alles
ein bisschen langsam 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, Antible zum Beispiel,
zieht halt rum, muss halt doch in 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, Armin macht das bei 80er Zeit.
Also Armin Gronacher ist wahrscheinlich der Typ, der hat Flask
gemacht.
Ganz viele Projekte.
Jochen weiß ja mehr, aber ja,
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, ich habe es auch so ein bisschen ausprobiert und dachte mir so,
nicht ganz das, was ich brauche.
Was hat dir denn gefehlt?
Der Stil, wie.
Vor allem das Project Scaffolding und wo die Sachen dann liegen.
Das ist halt alles opinionated.
Ich meine, ist halt, der hat 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 wird jetzt gerade eben von Armin entwickelt
und gerade ist es auch sehr aktiv, also der bringt da viele neue Releases raus,
aber man weiß ja nicht so wirklich, was damit passiert.
Genau, im halben Jahr hat er was anderes vor, hat einen anderen Job und hat ein neues Hobby oder sowas.
und das ist ein Test, das wir in der Zeit der PyTest-Sendung
in der Zeit der PyTest-Sendung
und das ist ein Testframework für Python.
und auch andere Tools
under the hood. Also, Rye zum Beispiel benutzt
Pip-Tools und natürlich benutzen viele
der anderen dann auch Pip.
Also, wenn man jetzt irgendwie Poetry-Add, irgendein
Package macht, dann nutzt
es, glaube ich, Pip oder PipX.
Ich bin mir gar nicht sicher.
Aber viele von diesen grundlegenden Tools
werden eben auch wiederverwendet und haben dann aber trotzdem
diese übergeordneten
Befehle wie Poetry-Add.
Ja, also PipX 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 GitHub 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 pipet die nach
Curl, also zieht die per Curl und pipet
die in die Shell oder so? So ähnlich, ja.
Aber es gibt mittlerweile neue Skripte und die anderen beiden
alten Skripte sind auch wieder deprecated und die soll man
nicht mehr verwenden und dann gibt es dann irgendeine Warning und es funktioniert
nicht mehr und es geht kaputt. Also gibt es übrigens auch
was zurückliefern. Das heißt, wenn jemand in deinem Netzwerk
sitzt, dann kann er dir da Dinge unterschieben,
wenn du das so machst.
Aber ja, ich verstehe,
warum Leute auf die Idee kommen, das so zu machen,
weil die Alternativen
sind auch alle nicht so toll.
Rust-Up ist auch per Call, übrigens.
Das an der Stelle mal.
Ja, also ich frage,
auch noch interessant, habt ihr
irgendwelche Pakete, die ihr in das System Python
mit direkt installiert?
ganz schlaff, der sagt ja alles nein pur, da kommt nichts dran, das ist
rein standard lib.
Also ich installiere tatsächlich immer...
Ich versuche tatsächlich zu vermeiden.
Also bei mir ist immer Django drin.
Also ich hätte gerne immer Startproject zum Beispiel.
Achso, damit du quasi im Template
direkt immer was erzeugen kannst.
Okay, ja gut. Und Rich ist immer drin,
weil ich habe immer so ein paar Sachen in meiner
Shell, die auf Python basiert sind
und da hätte ich gerne immer Rich drin und Typer hätte ich
halt in dem Fall auch gerne drin, weil ich halt
viele Kommando-Talentools, die ich im System weit benutze,
baue, deswegen auch da.
Ja, aber das sind dann schon wieder so
Dependencies, die ich dazu packen muss.
Ich habe tatsächlich noch nie Django benutzt.
Warum hast du das? Also du hast das gerade kurz erwähnt,
aber nicht so, dass ich das verstehen konnte.
Also das ist eigentlich nur ein einziger Grund.
Normalerweise,
wenn ich ein neues Projekt mache, benutze ich
Django Start Project,
was quasi den Scaffold macht und ich benutze dafür
mein eigenes Template. Du kannst halt dann bei Start Project
einen Pfad zu deinem Template angeben.
Und damit aber Start Project
verfügbar ist, muss halt Django schon da sein.
und deswegen zähle ich Django einfach direkt mit.
Ja, das ergibt Sinn.
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 irgendwie Tests-Directory und Source-Directory
und die meisten Tools, beispielsweise jetzt Hedge-Poetry,
die haben alle einen Befehl.
Könnt ihr irgendwie Hedge-Init, nee, Hedge-New
und dann mit so einer Init-Flag beispielsweise,
die erstellen dann das PyProject-Hummel-File
schon mal für einen, da sind dann auch viele
der Tools schon konfiguriert,
wie Black beispielsweise und dann
auch diese Folder-Struktur, also das
kann auch ganz nett sein, wenn man
das nicht alles selbst machen will. Ja, oder wenn man
das mag, ja. 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 er 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.
anfängt. Was empfiehlt man dem?
Ich würde fast sagen, gar keinen
Scaffold und alles selber bauen.
Ja, aber dann hat er halt eine schwere Leerkurve
erstmal vor sich.
Du musst alles aufräumen. Ich kenne halt so Kundenprojekte, wo die Leute
an irgendwas angefangen haben und denkst dir so, oh mein Gott.
Ja, ist das...
Ja, Cookiecut ist vielleicht gar nicht so doof. Es gibt ja auch für
Data Science Templates oder sowas und vielleicht kann man
da auch sein eigenes Template bauen. Ich weiß es nicht.
Ich hab's für Django halt.
Django Template.
Interessanterweise, man kann
mit diesem Django Start Project
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
tatsächlich am Anfang installiert, weil ich kann einfach
arbitriere Projekte mit meinem Django-Template bauen,
was im Prinzip
sowas ähnliches macht, wo einfach Ginger ersetzen
für irgendwelche Python-Files und halt
Dietrich-Strukturen bauen.
Mir ist fast so wie Cookie-Katar, nicht ganz so
mächtig und ich brauche es halt auch nur so für
kleine Sachen. Ich mache jetzt auch nicht so mega große Dinge, aber
ja. Und ein Problem, was man dabei
hat, ist halt, was ist, wenn sich an dem Basis-Template
irgendwas ändert und man möchte jetzt alle
Projekte, die man mit dem Template erzeugt hat,
auf den aktuellen Stand bringen. Wie macht man denn das?
Das ist eine gute Frage. Ich bin
da gerade dabei, mir was zu überlegen.
Und zwar ist 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 da zum Diff,
und PyTest.
Das heißt, ich muss die immer im Template bauen und dann
picken, anstatt dass ich Sachen selber
im Core ändere.
Ich konnte ja nur Sachen dazufügen und sonst
wird es halt immer Mesh-Konflikte geben, wo du halt immer dann manuell
rumfugen musst. Deswegen würde ich einfach
sagen, meine Konvention ist das dann einfach nicht zu machen, weil das
brauche ich auch nicht, weil ich habe halt dann E-Apps in der
Applikation, die für die Applikation da sind
und dann machen die halt nur Sachen, die die Applikation macht und Core-Funktionalität
kommt halt immer dann aus dem
aus der Basis raus. Aber, ja.
Oder auch
noch eine Frage, genau, gibt es irgendwie, dass bei
bei diesem ganzen Tool gibt es da auch so Funktionalitäten für
ich habe jetzt irgendwie 30 Repositories die alle relativ sind ich w jetzt gern zum Beispiel wei ich nicht Poetry Update oder was auch immer mal auf allen ausf Gibt es da Support
Ich hatte den Fall noch nie.
Das kann gut sein.
Also habe ich noch nie ausprobiert,
auch probieren müssen.
Ja, ich kenne das auch immer so,
dass dann Leute sich ihre eigenen Dinge zum Verwalten
von vielen Projekten schreiben.
Also ich glaube,
das ist sehr gefährlich, weil die Projekte
alle so unterschiedlich sind, da alle gleichzeitig
anfassen. Ja, also
zum Beispiel in der letzten
Jungle Chat Episode wurde Adam Johnson
gefragt, wie er das hinkriegt, dass er
70 populäre Repositories
manhint, oder
es gibt ja Leute, die da ganz viel haben.
Der erste Schritt ist, dass man alle Projekte
auf den gleichen Status bringen muss.
Und dann kann man mit Skripten drüber gehen.
Ja, genau.
Ja, ich habe auch so für die Produktivsachen
so ein Ansible-Book, das halt dann hingeht und
einfach Python updatet. Also zumindest Python-Mineware
oder so, oder Backpix geht ja noch, aber wenn du halt
Major, dann musst du halt eigentlich immer das Projekt
auschecken, gucken, ob es geht. Noch so eine
Frage halt, wie macht der das dann mit Tests
für Produktion, für so Builds
in verschiedenen Versionen, nimmt der da alle Tox
oder wie macht der das
am besten?
Ja, genau, also ich habe bisher immer Tox verwendet.
Auch weil es eben meistens
schon, wenn man jetzt irgendwie Hedge oder
ähnliches hat, dann mit konfiguriert ist.
Einfach der Einfachheit halber. Ah, okay, also
Hedge, Konfigurier, Tox auch direkt mit?
Soweit ich weiß, ja.
und dann sagt ihr einfach, okay, ich unterstütze
bis zu dieser und dieser Version runter und
dann installiert
also was macht Tox nochmal?
Tox macht verschiedene
Pythons. Ja, das erzeugt dir zum Beispiel
alle, also die unterschiedlichen
Virtual Envs 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 eine Möglichkeit hat,
ob die auf der Maschine schon da sein müssen
oder ob es selber...
Docker?
Nee, nicht Docker. Das glaube ich nicht.
Ich glaube, es kann die selber installieren.
Ich glaube, weil es nicht da sein muss.
Weil ich glaube...
Ich habe wahrscheinlich alte Versionen
nicht mehr, aber die Tox-Singer testen auch
gegen alte Python-Versionen.
Und das hat eigentlich immer funktioniert.
Also mein
Mein Guess wäre an der Stelle, ja,
Tox macht das irgendwie selber, aber
ich weiß es auch nicht genau.
Es gibt auch Nox,
auch noch ganz interessant,
weil ich habe auch schon viel zu viel Zeit damit verwendet,
irgendwie Tox
so zu konfigurieren, wie ich das gerne hätte
und es dauert
immer länger, als man denkt, dann funktioniert es doch nicht.
Und bei Nox kann man
einfach Python-Code hinschreiben
und das finden viele auch angenehmer.
Ich habe es aber auch noch nicht, weil jetzt habe ich schon so viel, jetzt unterliege ich der Sun-Cost-Fallacy und jetzt habe ich schon so viel Zeit in Toxinis investiert, jetzt gehe ich davon nicht mehr weg.
Ja, ich habe gerade mal nebenbei nachgeguckt und es sieht so aus, als müsste man das vorher installiert haben.
Ach doch, okay.
Okay, also tatsächlich PyEnv und dann alle Versionen, die du halt testen willst, einmal draufhauen und dann Tox sagen, wo die sind.
Ja.
Ja, ja, ja
lösen? Naja, nee, zum Beispiel, wenn du
jetzt eine Kombination hast aus Data Science
und zum Beispiel Web, dann gibt's halt
diverse Geschichten, so, weiß ich nicht,
irgendwie PyTorch oder
Dinge in diesem Ökosystem,
die halt nicht auf Python 3.11 laufen.
Das kannst du, geht halt noch nicht.
Ja, aber genau, aber das ist halt so ein Ding,
harte obere Abhängigkeitsschranke, warum
laufen die nicht auf Python 3.11?
Ja, aber das ist ja genau der Punkt, weil die
meistens haben ihre Top
dann gesetzt, oder
viele Pakete in diesem Data Science Umfeld, die gehen auch
nicht für Python größer
4, also größer 3, also nicht für 4.
Warum auch immer man das sagen möchte.
Ich würde sagen, warum nicht? Wenn Python 4
vielleicht läuft, hast du ja noch mal ausprobiert.
Naja.
Ja, das ist nicht so einfach.
Ja, ich weiß nicht, haben wir denn irgendwie
noch irgendwie ein größeres Thema bei diesem
Paket
Paketierungstools
Projektmanagement? Ich glaube vielleicht die
Quintessenz, dass es irgendwie nicht
das beste Tool gibt.
Das wünschen sich irgendwie alle, aber
bisher ist es leider noch nicht aufgetaucht.
Genau. Und es ist eben
auch schwierig, das hast du ja auch gerade beschrieben, dass man
nicht von Python aus dieses Tool
herstellen kann. Und es gibt immer mal wieder
Ansätze, das zu lösen, aber
so wirklich das beste Tool, was glaube ich
alle adoptieren
werden, kann man es im Deutschen sagen,
was alle benutzen werden, ist
irgendwie noch nicht so wirklich gefunden.
Du hast es ja auch gerade gesagt, zum Beispiel Rye
kann ja theoretisch alles,
aber wenn es dann nicht wirklich dem entspricht,
auch diesem Workflow oder wie es aufgebaut ist,
wie man das gerne hätte und man benutzt es dann
nicht, dann fällt man eben doch wieder auf
einzelne andere Tools zurück und dadurch entsteht das auch,
dass so viele Leute so viele verschiedene Tools benutzen.
Ja.
Ja, das ist schwierig.
UAC zum Beispiel
oder sowas, wie heißt das?
Das habe ich noch nie gehört.
Das ist auch so eine Rust-Implementierung von Python-Paketen
für VENVs und sowas.
Format
ActivateAd 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 Env und so das irgendwie
können muss, um halt irgendwas,
um sich ein Tool zu installieren, das
deine 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
was oder go oder so, aber
Also ich würde gerne noch
vielleicht ein, zwei Sachen zu diesem Packaging-Ding sagen, also mich
interessiert das zum Beispiel noch, also wann würde man denn zum Beispiel
ein Package auf PyPy
publishen wollen?
Also es gibt ja da recht viele Pakete
Ja, also ich denke
das kommt total drauf an, also ob man das
irgendwie gerne einfach mal ausprobieren
will, habe ich auch schon häufiger mal mitbekommen, dass Leute
wirklich einfach mal
sich ein bisschen einlesen möchten in diese ganze Thematik
und wie funktioniert das überhaupt und dann so ein kleines
als Beispielprojekt schreiben, weil man muss ja nicht viel machen. Man kann an sich einfach
einen Account erstellen und dann kann man sein Paket hochladen und zugänglich machen.
Darum muss man, glaube ich, auch sehr aufpassen, was man sich so installiert von PyPI.
Genau, oder dass man, was auch häufiger vorkommt, das ist jetzt dann, dass man so einen internen
Packaging-Index benutzen würde, wenn man beispielsweise in einem großen Unternehmen arbeitet
und Code zwischen verschiedenen Gruppen oder Abteilungen teilen möchte.
So eine Core-Library quasi, so eine eigene.
Ja, genau, dass man das dann hochlädt, sodass andere das wieder installieren können.
Genau.
Es gibt, 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 Poetra drüber geredet,
dass da so viele offene Issues waren,
teilweise, dass man häufig
auch vergisst, dass da eine Person
hinter sitzt, die das eventuell noch in ihrer freien Zeit
macht und
dass man das auch ganz häufig
wertschätzender
beurteilen muss, als man es tut, wenn Dinge nicht
funktionieren. Das ist total krass, also wie soll ich
das denn jemals schaffen? Also welche
Freizeit.
Ja, das ist ja auch
ein sehr verbreitetes
Problem, dass Leute dann halt
irgendwie,
also, dass dann Maintainer von
so Projekten verschwinden, liegt ja häufig daran,
dass sie das dann halt irgendwie hinkriegen,
aber man kriegt das halt nur eine Zeit lang
irgendwie hin und irgendwann ist man halt einfach durch
und dann ist halt,
dann geht man halt irgendwie
was mit Holz machen oder so und das Projekt
ist halt nicht mehr Maintainer.
Ja.
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.
die sich gegenseitig nicht sehen können.
Aber die Community ist auch, finde ich,
sehr wertschätzend und freundlich. Also wenn ich jetzt auf
Python-Konferenzen war, die Leute sind ja
wirklich nett. Man muss dann irgendwie Sorge haben,
Vortrag zu halten und Fehler zu machen, weil
da sitzt niemand, der dich dann
ausbuht oder irgendwie sagt, boah, was hast denn du jetzt
für ein Mist fabriziert?
Also ich finde, die Leute in der Python-Community
sind schon sehr freundlich.
Die Leute, das macht immer mehr Spaß
als auch bei anderen Sachen, die ich so kennengelernt habe im Check-in-Feld.
Ja, und man muss auch sagen, dass die Python-Community
wiederhalten,
so ein gutes Beispiel ist für,
wie das gut funktionieren kann.
Das ist in anderen Communities nicht unbedingt so.
Also Python ist da doch besonders
angenehm, ehrlich gesagt.
Bewahrt einen natürlich nicht davor, von irgendwelchen Randoms
auf Reddit angeschrien zu werden, aber...
Nee, gut, das kann natürlich auch mal passieren,
aber generell ist es, und vor allen Dingen
ist es halt auch besser als bei anderen.
Wir erinnern uns ja vielleicht selber an junge
Jahre, wo man vielleicht selber mal nicht immer
den Ton getroffen hat, den man eigentlich sich als Erwachsener
hätte überlegt.
mit PyT und so.
Manchmal, ja.
Ja, mir passiert das nie.
Ich bin immer freundlich,
immer höflich, immer gut drauf.
Ja.
Ja, ansonsten, ich weiß nicht mehr,
ich habe sonst auch nicht...
Habt ihr noch ein Packaging-Thema?
Oder ein Management-von-Environment-Thema?
Nee, aber ich fand
dieses Automatic-Speech-Recognition-Thema
auch noch total interessant.
Ich weiß nicht, ob du Lust hast,
darüber zu reden?
Ich würde da super gerne drüber reden, aber ich darf leider nicht.
Ach so, okay.
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,
für Environment Management oder Painting,
da haben wir so die meisten Tools so besprochen,
es gibt noch so ein paar mehr,
die wir jetzt nicht so gesprochen haben.
Ja, aber ich weiß auch nicht, ob die wichtig sind oder relevant.
Wir können ja auch einfach den
Vortrag verlinken
oder auch den Blogpost, da ist dann auch nochmal
das Ganze ein bisschen grafischer dargestellt, das finde ich
hilft natürlich auch für die
Übersicht. Es gibt eben auch ein paar
Tools, PyFlow zum Beispiel, haben wir gar nicht
angesprochen, das habe ich auch mit aufgenommen, aber das
ist so ein klassisches Projekt, was mal
angefangen wurde und was nicht
mehr maintained wird und dementsprechend auch nicht unbedingt
empfehlenswert ist,
das zu benutzen.
Ich habe es mal ausprobiert und habe sofort ganz viele Fehler
gehabt, aber da sollte man auch immer
drauf achten, was man sich da für ein Projekt
anschaut, ob da wirklich
regelmäßig Releases rauskommen und die
Issues auch abgearbeitet werden.
Ja, ich würde auch sagen, tatsächlich, also insgesamt bei
Libraries so ein bisschen die Frage, also
manchmal tendiert man ja so ein bisschen dazu, immer den neuesten
heißen geilen Scheiß zu benutzen.
Wenn der 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, 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 gut sein.
Ja, alleine schon auch, weil dann
man in den Issues ja häufig
genau das Problem
findet, was man gerade hat und dass das schon
beantwortet wurde. Alleine sowas kann ja unheimlich
hilfreich sein, dass einfach
solche Probleme schon besprochen wurden
und schon zig Leute das gleiche hatten.
Ja, genau.
Und man kann ChatGPT fragen,
weil es war vor 2021
schon irgendwie etwas,
was man finden konnte.
Ja, das ist halt genau.
Ich weiß nicht. Das finde ich zum Beispiel bei Django
immer toll.
Ich mag ja fast API.
Ich mag das sehr gerne. Ich mag auch PyLentic.
Ich finde den Ansatz super.
Aber das ist etwas, was bei Django
und
und die Leute, die es benutzen, denken sie so, oh nein.
Ja gut, aber es ist halt auch so ein Fade-off.
Du hast natürlich einerseits Interessen geleitete Entwicklung dann
und die ist halt nicht mehr vielleicht so ganz neutral.
Ja, vor allen Dingen, weil Leute dann irgendwann ihr Geld wieder haben.
Ja, aber das ist ein Problem, aber eine andere Frage ist halt auch,
du hast tatsächlich dann halt Zeit da und Geld da, Sachen zu bauen.
Ja, also brauchst du ein Geschäftsmodell, willst du eins haben, willst du nichts.
Und was immer ganz schlecht ist, wenn die Leute auf einmal halt ihr Geschäftsmodell
dann so für dich 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 der Community
wo nicht eine Firma dahinter steht
und wenn man halt eine Firma hat, dann ist immer
es ist tendenziell
eher kurzlebiger, weil vielleicht
haben Firmen dann auch mal andere Prioritäten
Kleine Anekdote am Rennen, ich weiß nicht, ob ihr es mitbekommen habt
und ob ihr euch damit auskennt, aber es gibt
Unity Game Engine
und das muss halt ganz
viel Open-Source oder irgendwie so
Indie-Studios. Die haben halt auf Unity
gesetzt und halt da ihre Spiele entwickelt.
Und die haben dann irgendwie gesagt, so ja,
neue Version jetzt übrigens. Ach, und alle Projekte,
also auch alle, die ihr irgendwann mal angefangen habt,
die sollen jetzt bitte pro Installation
so viel Geld zahlen.
Das war natürlich auf einmal
geknallt. Ich würde sagen,
ist tot. Mal gucken.
Ja, es war sehr blöd.
Und die Leute müssen jetzt alle ihre Projekte umziehen und so.
Die sind jetzt wieder mal zurückgerudert, wie es
halt immer so ist. Kommen wir so raus. Aber
solche Sachen sind natürlich gefährlich.
und PyTest.
Dominik Pintscher,
Jürgen Lange,
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 Obstlos nicht geht,
ist es halt schwierig.
Also ich versuche
auch immer tatsächlich bei den Konzernen, wo ich irgendwie so
da bin, irgendwen zu bewegen,
dass das so Geld zurückgibt,
also dass die zumindest dann so Spenden machen an Projekte
oder so, aber die hören dann immer so, ja, ja, total tolle Idee, würden wir auch total gerne machen, aber nein.
Passiert eher selten, leider.
Ja, denen ist das dann egal.
Man müsste halt einen Grund dafür liefern können und das ist, glaube ich, halt auch eins
der Dinge, wo man sich über Sachen überlegen müsste, wie man das hängt.
Also es gibt ja diverse Ideen.
Ah, ich finde übrigens genau dieses Material Theme für MKDocs, du hattest das eben erwähnt,
der Autor davon, der hat einen sehr schönen Weg gefunden, um damit Geld zu erzielen.
Der lebt ausschließlich davon
und der
lebt eigentlich quasi davon,
dass ein Unternehmen einen Grund gibt,
ihm Geld dafür zu bezahlen. Und zwar
gibt es halt alle Features
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 dafür.
Ja, also ich finde auch
diese, also ich muss halt auch
darauf angewiesen sein, dass ich jetzt
Open Source-Wörter, die ich benutze, dass ich die für alles nutzen kann.
Also auch für Business, weil sonst kann ich die halt für meine Arbeit
nicht verwenden. Was aber halt
doof ist, wenn es halt nie, wenn
irgendjemand damit richtig viel Geld mitfindet, der halt nichts zurückgibt.
Das ist halt irgendwie so der Deal dann gebrochen und die Frage ist halt,
ob man das lizenztechnisch irgendwie lösen kann. Ich würde sagen, eher nicht.
und das ist halt eher kacke.
Also bei mir fühlt es sich halt so, dass ich das gar nicht verwenden kann,
weil dann ich sonst Designsprobleme kriege,
die ich halt nicht haben darf.
Deswegen kann ich die Software mit AGPL nicht verwenden
für Arbeitsprojekte, sondern nur irgendwie in der Freizeit.
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, das ist notwendig.
Aber schwierig, weil du halt davon abgewiesen bist, dass das so dieses Spenden-Ding
eigentlich, also meiner Meinung nach müsste so der Staat so ein bisschen
mit der Gießkanne vielleicht sogar dahin gehen und was machen. Gerade bei OMSOS.
Das hat ja noch viel zu wenig für sich entdeckt, weil also auch Behörden und so sind ja abhängig von sowas. Und ich finde,
das wäre eigentlich so eine gute Sache, dass man sagt, okay, es gibt jetzt so 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, dass es so schwierig ist. Ja, nach so irgendwie so ein
Prozess und dann so, ja.
Aber ja, vielleicht wäre tatsächlich
da einfach das mit Steuergeld, aber
ja, ich sehe nicht,
dass das passiert.
Ja.
Habt ihr einen Pick der Woche? Pick der Folge?
Oh.
Habe ich irgendwelche Picks?
Hm.
und PyTest.
Quad Template irgendwo liegen oder sowas und das ist halt
direkt mit drin.
Ja, die Idee sozusagen ist,
Class-Based Views ist halt
in general problematisch, weil man
erbt von ganz vielen Dingen und die
Dinge erben wieder von ganz viel und oft hat man das Problem,
dass man nicht weiß, welche Methode muss man
denn jetzt überschreiben oder
welche darf man auf gar keinen Fall überschreiben und
wann passiert eigentlich was? Jochen ändert da an der Stelle seine Meinung
auch immer, wie seine Hosen,
weil ab und zu reden wir immer drüber,
dann fragt man sich, was ist die Class-Base?
Nein, okay, nicht ganz.
aber, also ich mag Class-Based Views
hinterher immer noch sehr gerne
Ja, also ich finde Class-Based Views
im Prinzip auch nicht schlecht, nur die sind schon sehr kompliziert
und quasi so Vererbungs-Hierarchien
sind halt auch etwas
Ja, aber dann machst du halt einfach keine Vererbung, sondern erbst halt einfach noch von einem View
und dann hast du aber eine wunderschöne
Interface
Wenn du den Form-View nimmst, der erbt halt von
fünf unterschiedlichen Sachen
Ja, dann nimm halt keinen Form-View
Ja gut, okay, klar, aber
die Class-Based Views sind halt so komplizierte
Vererbungs-Hierarchie und
und man braucht dann halt sowas wie
Classy Class-Based Views,
gibt so eine schöne Seite, wo man dann halt sehen kann
und
es ist halt vielleicht einfach
ein bisschen viel und deswegen sind
viele auf der, nee, ich verwende
nur Funktionen als Videos.
Ja, man hat dann If, Request, Message,
Post und sowas und boah.
Ja, hat dann auch Nachteile, klar.
Und jetzt die Frage, gibt es was dazwischen und
genau, es gab dann irgendwann von
Tom Christie Vanilla Views,
sozusagen, um halt diese
diese ausufernde Vererbungshierarchie in den Griff zu kriegen.
Aber das ist halt
ein bisschen sehr wenig. Und dann war halt sozusagen
die Idee der Neapolitanen,
es muss ein bisschen mehr sein als Vanilla.
Also das ist quasi das, wenn man das nicht kennt,
also hier ist das immer, ich heiße das ganz schrecklich,
der Name Fürst Pückler
oder so.
Und ich glaube, die internationale
der Name dafür ist Neapolitan.
Und deswegen
es war halt sozusagen die Idee, es ist ein bisschen mehr als Vanilla,
aber nicht sehr viel mehr.
Interessant.
Also ich kann immer empfehlen,
quasi Themenwechsel, anderer Pick,
was ich auch vorhin schon erwähnt habe, Material für
mkdocs, finde ich ein super
cooles Package, wo man wirklich
einfach tolle Dokumentationen bauen kann,
was doch
meiner Erfahrung nach viel zu selten gemacht wird.
Mit was ist die Basis? 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 stand was im Readme-File,
dann gab es noch eine Confluence-Seite, manches
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.
Würde ich auch bevorzugen,
was findest du da 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,
aber
ja, ja, nee, das ist schon toll.
Okay, ja, was könnte ich denn
Okay, ich picke mal was ganz anderes
Du hast ja eben schon mit Rezepten
so ein Buch irgendwie
da reingeguckt
Ja, wundervoll, das
Ottolenghi Flavor, das Gemüsekochbuch
Und zwar
gibt es den
gibt es ein schönes, wenn man auf Mac ist
gibt es eine sehr, sehr
schöne App, die nennt sich
Paprika Receipt Manager
und genau
das verwende ich seit einiger Zeit
und das ist ganz toll. Hast du das nicht schon mal gesagt?
Habe ich das schon mal gepickt? Oh nein!
Ich weiß nicht, ob du das gepickt hast, aber wir hatten es schon ein paar Mal.
Ah ja, okay, kann sein.
Ich sage immer das Gleiche.
Ja, ich habe
für mich auch dabei. Aber es ist gut,
dass ihr das nochmal gesagt habt, weil ich hatte es nicht mehr auf dem Schirm.
Also ich finde, manchmal
muss man einige schöne Sachen nochmal ein paar Mal
sagen. Man kann Dinge auch öfter sagen.
Wer weiß, wer immer bis zum Ende von jeder Folge
bleibt und wenn wir gerade so spannende Folgen haben,
wie wir manchmal haben wir spannende Folgen,
dann, wer weiß, wie viele Leute am Ende noch übrig sind.
Genau.
Ja.
Dann ganz vielen herzlichen Dank an den Nena, dass du da warst.
Vielen, vielen Dank.
Danke, dass ihr mich angeladen habt.
Und ja, bleibt uns gewogen, schaltet uns weiter rein,
morgens, abends und so weiter und wir wünschen euch
eine wunderschöne gute Zeit und bis zum nächsten Mal.
Und hoffentlich bis in gar nicht mal allzu langer Zeit.
Ja, erliegt mal das, wenn es nicht so viel Zeit.
Ja, wir haben noch so ein paar Sachen.
Gut, bis dann. Tschüss.