Zuerst einmal danke für die ausführlichen Antworten!
lunar hat geschrieben:Ehrlich gesagt, nein. Ich erkenne immer noch kein Szenario, in dem Dein "venv" obligatorisch wäre. Ich sehe nicht einmal irgendwelche konkreten Vorteile in dem beschriebenen Szenario mit mehreren, voneinander abhängenden Repos. Ich hätte einfach ein "virtualenv" erzeugt, die Abhängigkeiten mittels setuptools dorthin installiert [1] und anschließend dieses "virtualenv" zum Testen genutzt.
Ich möchte auch nicht sagen, dass das Skript obligatorisch ist
Man kann das was es macht, problemlos auch ohne das Skript erreichen, das habe ich in meinem Post ja auch geschrieben. Für mich ist es blos Komfort, den
ich mit anderen Mitteln nicht zu erreichen vermag, deshalb gefällt mir diese Diskussion jetzt auch schon viel mehr, da ich nun sehe, was auch möglich ist. Es geht mir ja auch nicht darum, das Projekt zu verteidigen (Projekt ist jetzt fast übertrieben, es ist ja mehr ein Codeschnipsel), sondern nur zu erklären, was ich mir dabei gedacht habe und da ich das nun dargelegt habe, die Möglichkeit zu haben, andere Wege kennenzulernen, die mein Script gutmöglich überflüssig machen.
An diesem Punkt ist es vielleicht noch sinnvoll anzufügen, dass auf meiner Hauptmaschine Windows läuft, und ich leider nicht in den Genuss von Symlinks komme, ausser ich gehe über cygwin.
lunar hat geschrieben:Ich hätte einfach ein "virtualenv" erzeugt, die Abhängigkeiten mittels setuptools dorthin installiert [1] und anschließend dieses "virtualenv" zum Testen genutzt.
Bei dem was ich gemeint hatte, bezog ich mich auf das Testen während des Entwicklungsprozess. Da möchte ich nicht immer die Installationsroutine ausführen nur weil ich eine Zeile geändert habe. Aber ich glaube nicht wirklich, dass du das gemeint hast.
DasIch hat geschrieben:virtualenv nutzt ausschliesslich symlinks, kopiert wird nur env/bin/activate(und andere Skripte?).
This script only symlinks a small portion of the standard library into the environment, and so on Windows it is feasible to simply copy these files over.
Ok, wir hatten beide nicht ganz recht. Das steht im Vergleich zu dem, was es anders macht als virtual-python. Aber wenn du ein Paket in eine solche Python Umgebung installierst, wird es dann nicht dorthin kopiert, auch wenn du sie schon hast? Vielleicht liegt das ja auch daran, dass ich Windows habe. Möglich wäre ja, dass auf Linux die Pakete an einem zentralen Ort mit einem Versions-Suffix abgelegt werden, und dann per symlink darauf verwiesen wird.
Normalerweise, hat man jedoch nicht nur Code in den Repositories. Man hat noch Dokumentation, Tests und je nachdem noch andere Dateien, die nicht wirklich in die Python-Umgebung gehören. Des weiteren müsste man dann einen Symlink anlegen, da der Code ja dann in einem Unterordner des Git-Repositories liegt.
Also so oft muss ich Tests von anderen Projekten nicht ausführen und die Dokumentation findet sich auf der jeweiligen Webseite. Unabhängig davon kann man aber dafür problemlos git submodule nutzen.[/quote]
Ich weiss nicht genau, was du mit den "Tests von anderen Projekten". Ich wollte sagen, dass ich in der Python-Umgebung ja dann nur den Code aus dem Repository haben kann, da er sonst ja nicht gefunden werden kann, wenn der Code in einem Unterordner des Repositories liegt, und ich - wegen Windows - keine symlinks verwenden kann, und auch auf neuen Versionen das nicht gut gelöst wird, obwohl es ja seit Vista unterstützt wird.
Ja klar, du hast Recht wenn du sagst, dass ich stattdessen einfach verschiedene Repositories bzw Submodules verwenden könnte.
Letztendlich kann man aber auch einfach virtualenv nutzen und über pip die Abhängigkeiten aus den Git Repositories installieren, damit habe ich den entscheidenden Vorteil den Code nicht ändern zu müssen und alles was distribute nutzt kann man so installieren dass symlinks verwendet werden so dass Updates problemlos statt finden.
Ok, ich schätze das erledigt dann meine Frage von vorhin erledigt, zu einem Teil zumindest. Wie funktioniert es denn genau?
Womit wir zur Frage kommen was machst du eigentlich wenn du keine Zugriff auf die fremden Repositories hast?
Das verstehe ich jetzt nicht. Was hat venv mit Zugriff auf Git-Repositories zu tun? venv hat ja gar nichts mit Git am Hut, es war nur der Kontext, in welchem ich es verwende.
Du wirst mir nun antworten, dass Du weder setuptools noch virtualenv nutzt, worauf ich Dir anschließend meine Zweifel an Deinen Entwicklungsprozeduren darlegen werde, denn distutils/setuptools zum Deployment und virtualenv zur Bewältigung der Abhängigkeiten sind eigentlich obligatorisch für vernünftige Entwicklung mit Python.
Ja da hast du Recht. Ich bin in Sachen Python auch noch sehr neu
Nur sind diese Dinge auf Windows einfach wirklich argmühsam, wie ich jetzt gerade festgestellt habe, als ich setuptools installieren wollte, und der dachte ich hätte kein Python installiert.
Wäre es Richtig zu sagen, dass venv eine Teilmenge von virtualenv ist, wobei es einfach die Aufgabe des Betriebssystems die Symlinks aufzulösen übernimmt?
