Transcript: Environment Management und Packaging

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast Episode 51.

Wir hatten eine relativ lange Sommerpause.

Ja, ungeplant.

Ungeplant, war ein bisschen, sorry, was dazwischen gekommen ist.

Wir haben uns auch schon viele Leute geschrieben.

Wir haben uns auch schon viele Leute geschrieben.

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.

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

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

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

in der Zeit der PyTest-Sendung

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,