Probleme beim Erzeugen des env

[trutzig89182]

Hi, ich höre nach und nach alte Folgen vom Python Podcast durch. Ich wollte gerne bei der Textklassifikation mal in das Jupyter Notebook schauen. Leider habe ich Probleme beim einrichten der Umgebung. Nach ´conda env create´bleibt mein MacBook nun seit fast 24 Stunden bei „solving environment“ stecken.
Ich hatte vorher Anaconda deinstalliert und Miniconda installiert. (Da war eure Diskussion im Podcast hilfreich.)

Ich vermute, dass das Problem irgendwo auf meiner Seite besteht, aber vielleicht gibt es ja auch irgendwelche Konflikte zwischen den geladenen Packeten.

[ephes]

Hallo David,

nee, das ist wahrscheinlich kein Problem auf deiner Seite 😅. Ich habe dieses Repository schon sehr lange nicht mehr angefasst. Ursprünglich habe ich es mal 2018 für eine ML-Anfängerschulung im Linuxhotel erstellt.

Vielleicht versuche ich diese Woche mal, das Ding wieder in einen benutzbaren Zustand zu bringen. Eigentlich würde ich ja auch gern mal ein bisschen was zu LLM-Finetuning und Deep-Learning überhaupt machen. Dazu ist hier noch überhaupt nix drin. Also danke schonmal für den Anstoss, ich sage hier Bescheid, wenn das wieder installierbar sein sollte und würde mich dann natürlich auch über Feedback freuen, ob das dann geklappt hat.

Viele Grüße
Jochen

[trutzig89182]

Bei der Gelegenheit, die Installatinosanleitung geht glaub ich davon aus, dass die yml-File im ds_tutorial Unterordner liegt.

[ephes]

Bei der Gelegenheit, die Installatinosanleitung geht glaub ich davon aus, dass die yml-File im ds_tutorial Unterordner liegt.

Ja, die Anleitung muss ich dringend mal anfassen. Das conda env create sollte jetzt aber gehen. Das numpy notebook sollte auch schon wieder tun, das pandas ist noch in progress :).

Weiß noch nicht so recht, wie das Bootstrappen des Environments am besten funktionieren soll. Mögliche Optonen:

• nbdev - das ganze Repo hier ist sehr notebooklastig, konsequenterweise könnte man dann einfach alles in den notebooks machen inklusive der Tests und gemeinsam genutztem Code, ist ein bisschen exotisch..
  • Vorteil: Tests sind in den Notebooks mit drin, gemeinsam genutzter Code kommt auch aus den Notebooks
• Ein Paket bauen, das dann editierbar installiert wird und selbst die Abhängigkeiten Richtung Pandas etc mitbringt, aber eher mit flit oder hatch oder pip pur als mit poetry.
  • Vorteil: Eigene Skripte gehen, gemeinsam genutzter Code ist gleich in einem Paket, das via PyPi installierbar ist. Hmm, vielleicht auch nicht editierbar sondern nur via PyPi für reine Nutzer?
  • Nachteil: Nutzer eines data science Tutorials interessieren sich wahrscheinlich nicht dafür, wie das mit den Paketen funktioniert. Ok - wahrscheinlich müssen sie das auch nicht wissen, weil sie ja nur einmal installieren müssen...
• Kein Paket bauen
  • Vorteil: Am einfachsten
  • Nachteil: Funktioniert das dann auf allen Platformen mit den Importen? Der PYTHONPATH muss stimmen etc..

Und dann noch die Frage, ob conda oder pip. Wahrscheinlich ist das heutzutage egal, ich probiere beides mal aus und überlege dann noch mal.

P.S.: Ich denke hier nur laut und erwarte keine Antwort 😄

[ephes]

Ach, was soll der Geiz, ich probier das mal mit nbdev #10

[ephes]

Ok, bin noch nicht wirklich weit gekommen, aber immerhin habe ich jetzt einen Plan 😏📜✨.

• Erstelle ein neues ds_tut-Paket
• In der ersten Zelle eines jeden Notebooks wird irgendeine ds_tut.setup-Funktion aufgerufen

Ich habe mir mal angeschaut, wie das im Buch Deep Learning for Coders gelöst wurde. Vielleicht kann ich das einfach auch so machen? Die Notebooks aus dem Buch kann man einfach in google colab öffnen und ausführen. Das ist eigentlich ganz nett, weil man sich nicht mit der Python-Installation und dem Erstellen eines virtuellen vs herumschlagen muss. Aber wenn man so etwas machen will, kann man die Abhängigkeiten nicht gut über eine environment.yaml oder requirements.txt definieren. In den Notebooks des Deep-Learning-Buches gibt es am Anfang immer eine Zelle, die ein Paket namens fastbook via pip installiert und dann fastbook.setup_book() ausführt. Das Paket fastbook bringt alle Abhängigkeiten mit, die erfüllt sein müssen, damit die Notebooks laufen. Die Funktion setup_book prüft, ob sie auf einem Colab-Notebook läuft und mounted dann das Google Drive des Benutzers nach /content, um dort Daten speichern zu können. Lustigerweise ist das fastbook Paket nicht im fastbook Repository selbst, sondern in diesem hier. Und dort wird auch nicht nbdev für das Paket verwendet, sondern es wurde alles von Hand in fastbook.__init__ eingefügt. Was natürlich richtig sein kann, wenn man die nbdev-Mechanismen vielleicht für die Buch-Notebooks braucht. Im neuesten course22 ist das alles wieder anders. Okay, wie auch immer.

Die Idee, ein Paket wie fastbook zu haben, finde ich grundsätzlich gut. Es gibt einen Platz für Code, der von mehreren Notebooks gemeinsam genutzt wird. Funktionen wie setup_book können auch sehr nützlich sein. Ob es eine gute Idee ist, eine Liste von Abhängigkeiten für alle Notebooks zu haben, weiß ich nicht. Vielleicht geht das auch für das Deep Learning Book. Ich glaube, ich installiere die Abhängigkeiten einfach direkt im Notebook. Dann kann man auch mal Notebooks mit komischen Abhängigkeiten haben, oder man kann zumindest einen Teil der Notebooks noch benutzen, wenn es irgendwo in den CUDA-Untiefen Konflikte gibt. Ich denke, ich nenne das fastbook Paket einfach ds_tut und packe es in ein neues Repository. Damit umgehe ich das Problem, dass ich dann zwei verschiedene Arten von Notebooks in einem Repository habe. Und welche Dokumentation sehe ich eigentlich für das Repository? Die für das Paket ds_tut oder die für das Tutorial?

Mit der Frage, wo die Notebooks laufen sollen, werde ich mich dann wieder beschäftigen, wenn die Verwendung von GPUs obligatorisch wird. Vielleicht ist kaggle besser als colab, ich könnte es auch auf einer meiner Maschinen deployen. Mal sehen.