Events/freies hacken #74
Conversation
|
Wie in Issue schon geschrieben: Für mich ist das keine gute Idee, jeden Mittwoch mit Freies Hacken zu belegen, weil mein Kalender dann unübersichtlich wird und ich dann wahrscheinlich deabbonnieren würde. |
|
Über Tags könnte man das sortieren. Wie im Issue auch geschrieben, bevor wir viele events generieren, die wir alle nochmal anfassen müssen, sollten wir Startzeit/Dauer klären. Siehe #78 |
|
Offtopic: Damit wir die Merges nicht wieder bekommen, sollte beim Update die Option "Update with rebase" gewählt werden. Das lässt sich leider nicht voreinstellen. |
|
Ich habe jetzt die Events gelöscht und würde erstmal nur das Script in den Tools Ordner mergen. Wenn wir dann entschieden haben wie es mit den Events mit der Zeit weitergeht, dann mache ich nen neuen PR auf. |
24367dfa
force-pushed
the
events/freies_hacken
branch
from
9406056
to
1c0e3e2
Compare
|
Nimm Mal das draft raus. Und mach Mal eine |
timherrm
force-pushed
the
events/freies_hacken
branch
from
1c0e3e2
to
efd42af
Compare
so richtig? |
|
Dann ist das doch mal noch WIP. Der Teil, dass die Events in Jahresordnern landen fehlt auch noch. |
|
@24367dfa Kannst du so nochmal drüber schauen? |
There was a problem hiding this comment.
Das klingt vllt nach Nitpicking, aber ich habe mir inzwischen angewöhnt, für Python-Scripte immer auch einen Docker-Container zu definieren und im README die entsprechenden Aufrufe (mit Volume Mount) zu definieren. Wir tun uns damit mittel- und langfristig einen großen Gefallen.
Hintergrund ist, dass es ziemlich nervig sein kann, die passenden Dependencies im System zu haben, insbesondere weil es Bibliotheken gibt, die miteinander im Konflikt stehen.
Da auch virtual environments gerade nicht zuverlässig deploybar sind, ist ein Container die zuverlässigste Lösung.
Heißt konkret:
- Tool-Spezifisches Verzeichnis, damit wir nicht den Überblick verlieren (
git mv) - Dockerfile
- Entsprechender Container-Aufruf in der README
Wenn Du dabei Unterstützung brauchst, sag bitte Bescheid.
| ``` | ||
| Output: | ||
|
|
||
| ```bash |
There was a problem hiding this comment.
Wollen wir diesen Output wirklich im Repo haben?
There was a problem hiding this comment.
Mir ist das egal, ich kann es auch einfach wieder löschen. Möchte nur verstehen, was dein Gedanke dahinter ist, das zu löschen, damit ich es fürs nächste Mal weiß 😄
There was a problem hiding this comment.
Ich hab mich gefragt, was wir mit der Info im README machen - geht es darum, noch zu wissen, was dafür passiert ist? Dann würde ich die Info eher in die Commit-Message oder den PR schreiben.
There was a problem hiding this comment.
Für mich war es eher ein "so führst du es aus" und "das sollte dann dabei rauskommen, wenn alles funktioniert hat".
Hat für mich als Unwissender halt Sinn gemacht das da hin zu schreiben :D
Aber ja man sieht ja im Zweifel ob eine Fehlermeldung kommt oder Dateien in den Ordner geschrieben werden
|
@timherrm Nach dem Git-Workshop: Hast Du Lust, die Commits ein wenig zusammenzufassen? ;) |
No description provided.