GIT und venv

[paddie]

Hi,

ich möchte mich jetzt doch etwas genauer mit GIT beschäftigen . Ich will sowohl auf meinem Desktop als auch auf dem Laptop arbeiten. Ich möchte keine Plattform wie github oder gitea nutzen sondern git läuft auf meinem eigenen vServer (Debian).

Jetzt stellen sich mir (erstmal) zwei Fragen:

- Wie handhabe ich das mit dem venv? Wenn ich das Projekt per GIT synchronisiere muß ich ja auf dem Laptop auch erst einmal "alles" per Hand einrichten bzw wenn ich zwischendurch etwas hinzufüge das auch erstmal auf dem Laptop auch hinzufügen oder wäre es sinnvoll, das venv auch ins Repo reinzupacken?

- Was mache ich mit einer Datenbank (Postgres)? Die kann ich ja schlecht ins Repo packen (denk ich mal..). Mein erster Gedanke wäre, ich packe die Daten direkt in die DB die eh auf dem vServer läuft und greife dann über ein VPN oder ssh-Tunnel auf den vServer zu.

Danke schonmal für eure Tips .

Paddie

[sparrow]

Das Environment gehört nicht mit ins Repository sondern eine Übersicht der benötigten Module.
Die kann man sich mit "pip freeze" in eine Datei schreiben lassen. In der Regel heißt die requirements.txt , dann weiß jeder, was sie bedeutet.
Und auf einem anderen System kannst du das dann mit pip install -r dateiname eben jene Pakete einspielen lassen.

Das mit der Datenbank lässt sich nicht so einfach beantworten und kommt auf den Anwendungsfall an.
Ich habe in der Regel auf jedem System eine extra Datenbank laufen, weil die sich ja auch im Laufe der Entwicklung kaputt entwickeln kann und arbeite nie am Live-System.
Man kann einen Dump rudimentärer Anfangsdaten ins Repository packen, darf dann aber nicht vergessen den ständig an ein möglicherweise geändertes Datenbanklayout anzupassen.

[paddie]

Das Environment gehört nicht mit ins Repository sondern eine Übersicht der benötigten Module.
Die kann man sich mit "pip freeze" in eine Datei schreiben lassen. In der Regel heißt die requirements.txt , dann weiß jeder, was sie bedeutet.
Und auf einem anderen System kannst du das dann mit pip -r dateiname eben jene Pakete einspielen lassen.

OK, also dann vor dem commit einfach einmal pip freeze und dann die requirements.txt mit committen.

Das mit der Datenbank lässt sich nicht so einfach beantworten und kommt auf den Anwendungsfall an.
Ich habe in der Regel auf jedem System eine extra Datenbank laufen, weil die sich ja auch im Laufe der Entwicklung kaputt entwickeln kann und arbeite nie am Live-System.
Man kann einen Dump rudimentärer Anfangsdaten ins Repository packen, darf dann aber nicht vergessen den ständig an ein möglicherweise geändertes Datenbanklayout anzupassen.

In dieser Phase gibts ja erstmal kein Live-System . Aber das mit dem Dump ist natürlich auch eine Idee. Ich glaub ich werde das einfach mal ein Zeit ausprobieren

Vielen Dank schonmal für deine Tips

Gruß

Paddie

[__blackjack__]

Statt pip + requirements.txt könntest Du auch mal schauen ob pipenv etwas für Dich wäre.

[paddie]

Statt pip + requirements.txt könntest Du auch mal schauen ob pipenv etwas für Dich wäre.

Werd ich mir heute abend mal angucken.

Vielen Dank.

Paddie

[grum.py]

Statt Git gibt es übrigens auch noch unzählige (hinsichtlich der Bedienung deutlich weniger anstrengende) Alternativen. Gerade für ein Projekt mit einer einstelligen Zahl an Entwicklern empfehle ich selbst sogar SVN...

[__deets__]

Ich habe SVN und GIT lange genug genutzt, um sagen zu können: das stimmt nicht. Selbst mit nur einem Entwickler der einem Feature-Branch reintigrieren will ist das eine Qual. Eine (gegen meinen Willen) durchgeführte Umstellung eines Projektes von SVN auf GIT war schon innerhalb weniger Tage einer der größeren Aha-da-lagst-du-richtig-daneben-Momente die ich so beruflich hatte.

[grum.py]

Ich bin tatsächlich von Git und Hg auf eine Kombination aus SVN (für die großen Sachen), Fossil (für das meiste) und Darcs (für den Kleinkram) umgestiegen. Die längste Erfahrung, seit 2002 (edit: entschuldige, 2003), habe ich dabei mit SVN.

Git macht einfach zu oft zu viel kaputt.

YMMV.

[__deets__]

Was heißt denn kaputt machen? Das einzige das ich mir da entfernt vorstellen kann ist eine Fehlkonfiguration was binär und was Text Datei ist.

[grum.py]

Ich sag’s mal so: nicht mal im sehr ähnlichen Hg musste ich auch nur ein einziges Mal das Äquivalent zu „reset —hard“ nutzen - in Git andauernd. Das Mergen von parallel entwickelten Branches ist in Git einfach schlecht gelöst.

[__deets__]

Öh. Nein. Klingt eher danach es auf eine bestimmte Art machen zu wollen, die irgendwie gegen den Strich geht. Vor allem aber ist SVN konzeptionell so viel schlechter beim merge, das gerade DAS kein Argument für SVN ist.

Git ist nicht trivial, aber das ist ehrlich gesagt kein VCS.

[grum.py]

SVN ist ja auch für Cathedral und nicht für Bazaar da...
... Ich mach das meiste halt nur für mich, da sind meine Anforderungen ganz andere. Die Anforderungen von „paddle“ klangen aber auch nicht nach einem Projekt mit zig Mitarbeitern und Branches.

Und doch, natürlich gibt es (vergleichsweise) triviale VCS, etwa SCCS (das bis heute das Standard-POSIX-VCS ist). Aber sobald „remote“ oder gar „distributed“ zum gewünschten Feature wird - beides keineswegs immer der Fall -, wird es hässlich.

(Ich mag SCCS, aber leider gibt es keine Windowsversion, womit es für mich untauglich ist.)

[paddie]

Oha...jetzt gucke ich ein paar Stunden mal nicht hier rein... .

SVN ist ja auch für Cathedral und nicht für Bazaar da...
... Ich mach das meiste halt nur für mich, da sind meine Anforderungen ganz andere. Die Anforderungen von „paddle“ klangen aber auch nicht nach einem Projekt mit zig Mitarbeitern und Branches.

Du hast es erfasst . Ich bin ganz alleine und das ist auch "nur" ein Hobby-Projekt um Python zu lernen. Theoretisch würde es wahrscheinlich auch reichen, wenn ich einfach immer meinen Projekt-Ordner mittels rsync syncronisieren würde...aber das wäre 1.langweilig und zweitens lern ich dabei nichts...

SVN kenn ich noch von "früher" als noch fast alle OSS-Projekte damit gearbeitet haben. Aber irgendwie war das für mich schon lange "tot"...

[grum.py]

Tot ist, was niemand mehr nutzt. Und davon ist SVN weit entfernt. Selbst Mercurial ist töter. Und SVN ist echt gut geworden.