Wie kann ich Entwicklungsversionen von Python-Paketen handhaben, ohne auf SCM angewiesen zu sein?

Question

Ein Problem, das während der Pinax-Entwicklung auftaucht, ist der Umgang mit Entwicklungsversionen von externen Apps. Ich versuche eine Lösung zu finden, die keine Versionskontrollsysteme beinhaltet. Grund dafür wäre, dass ich nicht alle möglichen Versionskontrollsysteme auf meinem System installieren muss (oder das bei den Mitwirkenden erzwingen muss) und die Probleme behandeln muss, die bei der Erstellung der Umgebung auftreten könnten.

Nehmen Sie diese Situation (zu wissen, wie Pinax zum Verständnis von Vorteil sein wird funktioniert):

Wir Entwicklung an einer neuen Version von Pinax beginnen. Die vorherige Version enthält eine Pip-Anforderungsdatei mit expliziten Versionen. Ein Fehler tritt bei einer externen App auf, die wir gerne gelöst haben möchten. Um den Fehler in Pinax zu beheben, besteht der aktuelle Prozess darin, eine kleine Version der App zu erstellen, vorausgesetzt, wir haben die Kontrolle über die App. Apps, die wir nicht kontrollieren können, behandeln wir einfach mit dem Veröffentlichungszyklus des App-Autors oder erzwingen sie, Releases zu machen ;-) Ich mag es nicht, immer kleinere Releases für Bug-Fixes zu machen, in einigen Fällen möchte ich das auch sein Arbeiten an neuen Funktionen für Apps. Natürlich verzweigen wir die ältere Version und machen Backports so wie wir es brauchen.

Ich würde gerne einige Gedanken dazu hören.

Answer 1

Ich wollte damit sagen, dass die Lösung, die ich mir vor der Anfrage angesehen hatte, war, ein Pinax PyPI zu installieren und darauf Entwicklungsversionen zu veröffentlichen. Wir könnten eine Instanz von Chishop aufstellen. Wir verwenden bereits die --find-Links von pip, um auf pypi.pinaxproject.com auf Pakete zu verweisen, die wir selbst veröffentlichen mussten.

Answer 2

Könnten Sie das mit dem Versionsbezeichner "== dev" behandeln? Wenn die Seite der Distribution auf PyPI einen Link zu einem .tgz der aktuellen dev-Version enthält (wie sowohl github als auch bitbucket automatisch bereitstellen) und Sie "# ei = project_name-dev" an den Link anhängen, werden dies sowohl easy_install als auch pip verwenden .tgz wenn == dev angefordert wird.

Dies erlaubt es Ihnen nicht, etwas spezifischer als "neueste Tipp/Kopf", aber in vielen Fällen, die gut genug sein könnten, zu pinnen?

Answer 3

Die meisten Open-Source-Distributoren (Debian, Ubuntu, MacPort und andere) verwenden eine Art Patch-Management-Mechanismus. So etwas wie: Importieren Sie den Basis-Quellcode für jedes Paket als freigegeben, als Teerkugel oder als SCM-Snapshot. Verwalten Sie dann alle erforderlichen Änderungen zusätzlich mit einem Patch-Manager wie quilt oder Mercurial's Queues. Dann bündeln Sie jedes externe Paket mit allen angewendeten Patches in einem konsistenten Format. Oder URLs zu den Basispaketen und URLs zu den einzelnen Patches haben und diese während der Installation anwenden. Das ist im Wesentlichen was MacPorts tut.

EDIT: Um einen Schritt weiter zu gehen, könnten Sie dann die Menge der Patches über alle externen Pakete Version kontrollieren und , dass als eine Einheit verfügbar machen. Mit Mercurial Queues ist das ganz einfach. Dann haben Sie das Problem vereinfacht, indem Sie nur einen Satz von Patches unter Verwendung eines SCM-Systems veröffentlichen, wobei die Patches wie oben lokal angewendet oder für Entwickler verfügbar sind, um sie auf ihre Kopien der Basis-Release-Pakete zu ziehen und anzuwenden.

Answer 4

EDIT: Ich bin mir nicht sicher, dass ich Ihre Frage richtig lese, so dass das Folgende Ihre Frage nicht direkt beantworten kann.

Etwas, das ich in Betracht gezogen habe, aber noch nicht getestet habe, verwendet die Freeze-Bundle-Funktion von Pip. Vielleicht würde das funktionieren und das Paket mit Pinax verteilen? Meine einzige Sorge wäre, wie verschiedene Betriebssysteme behandelt werden. Zum Beispiel habe ich noch nie pip unter Windows benutzt, also würde ich nicht wissen, wie ein Bundle dort interagieren würde.

Die vollständige Idee, die ich versuchen möchte, ist ein Fertiger-Skript zu erstellen, das die Verwaltung der Bundles steuert, so dass Benutzer es einfacher machen, auf neuere Versionen zu aktualisieren. Dies würde jedoch ein bisschen Gerüstbau erfordern.

Eine andere Möglichkeit besteht darin, einen Spiegel der nicht kontrollierten Apps in einem konsistenten vcs zu behalten und dann Ihre gespiegelten Versionen zu verteilen. Dies würde die Notwendigkeit beseitigen, dass "jeder" viele verschiedene Programme installiert hat.

Abgesehen davon, es scheint die einzige echte Lösung ist, was Sie tun, gibt es nicht eine stressfreie Art, die ich gefunden habe.