Python 3 Entwicklung und den Vertrieb Herausforderungen

Question

Angenommen, ich ein Universal Endbenutzer-Dienstprogramm in Python geschrieben entwickelt habe. Zuvor hatte ich nur eine Version zur Verfügung, die für Python geeignet war später als Version 2.3 oder so. Es genügt, zu sagen: „Python herunterladen, wenn Sie müssen, dann diesen Skript ausführen“. Es gab nur eine Version des Skripts in der Quellcodeverwaltung (Ich verwende Git) im Auge zu behalten.

Mit Python 3 ist dies nicht mehr unbedingt wahr. Für die absehbare Zukunft muss ich gleichzeitig zwei verschiedene Versionen entwickeln, eins für Python 2.x und eine für Python 3.x Aus entwicklungspolitischer Sicht kann ich ein paar Möglichkeiten denken:

1. Pflegen zwei verschiedene Skripte in der gleichen Branche, gleichzeitig Verbesserungen sowohl zu machen.
2. Pflegen zwei getrennte Zweige, und Zusammenführen von Änderungen gemeinsame hin und her, wie die Entwicklung fortschreitet.
3. Pflegen nur eine Version des Skripts, und überprüft in einer Patch-Datei, die das Skript von einer Version auf den anderen umwandelt. Wenn genügend Änderungen vorgenommen wurden, dass der Patch nicht mehr die Konflikte sauber, lösen gilt und einen neuen Patch erstellen.

Ich bin Neigung zur Zeit in Richtung Option 3, da die ersten beiden eine Menge fehleranfällig Eintönigkeit verbunden wäre. Aber die Option 3 scheint chaotisch und mein Source-Control-System sollte Patches für mich zu verwalten.

Für den Vertrieb Verpackung gibt es mehr Optionen zur Auswahl:

1. Angebot zwei verschiedene Download-Pakete, eins für Python 2 und ein für Python 3 (die Benutzer wissen müssen, um für die richtigen herunterladen, was auch immer Version von Python sie haben).
2. Angebot einer Download-Paket, mit zwei verschiedenen Skripte innerhalb (und dann muss der Benutzer weiß, die richtigen laufen).
3. Ein Download-Paket mit zwei versionsspezifische Skripts und ein kleiner Stummel Loader, der in beiden Python-Versionen ausgeführt werden können, die für die Python-Version installiert das richtige Skript ausgeführt wird.

Auch hier bin Neigung ich zur Zeit in Richtung Option 3 hier, obwohl ich nicht versucht habe, noch so einen Stub Loader zu entwickeln.

Jede andere Ideen?

Answer 1

Edit: meine ursprüngliche Antwort auf dem Stand des Jahres 2009 basiert, mit Python 2.6 und 3.0 als die aktuellen Versionen. Jetzt, mit Python 2.7 und 3.3, gibt es andere Möglichkeiten. Insbesondere ist es nun durchaus machbar 3 eine einzige Code-Basis für Python 2 und Python zu verwenden.

Siehe

Porting Python 2-Code zu Python 3

Original Antwort:

Die offizielle Empfehlung sagt:

  

Für die Portierung bestehender Python 2.5 oder 2.6   Quellcode zu Python 3.0, die besten   Strategie ist die folgende:

     

  

1. (Voraussetzung :) mit hervorragender Testabdeckung starten.

  

2. Port zu Python 2.6. Dies sollte nicht mehr Arbeit als die durchschnittlich Port sein   von Python 2.x auf Python 2. (x + 1).   Stellen Sie sicher, dass alle Tests bestanden.

  

3. (Still 2.6 unter Verwendung von auf dem -3 Kommandozeilenschalter einschalten :). Das ermöglicht   Warnungen über Funktionen, die sein wird,   in 3.0 entfernt (oder Änderung). Führen Sie Ihre   Testsuite wieder, und beheben Code,   Sie erhalten Warnungen über, bis es   keine Warnungen links, und alle Tests   noch passieren.

  

4. Führen Sie den 2to3 Source-to-Source-Übersetzer über den Quellcode Baum.   (Siehe 2to3 - Automatische Python 2 bis 3   Code Übersetzung für mehr zu diesem Thema   Werkzeug.) Führen Sie das Ergebnis der   Übersetzung unter Python 3.0. Manuell   beheben Sie alle noch offenen Fragen auf, Befestigungs   Probleme, bis alle Tests bestanden wieder.

  

     

Es ist nicht zu versuchen, empfohlen zu schreiben   Quellcode, der unverändert läuft unter   sowohl Python 2.6 und 3.0; Sie müßten   verwenden, um einen sehr verzerrtes Programmierstil,   z.B. print-Anweisungen zu vermeiden,   metaclasses, und vieles mehr. Wenn du bist   Aufrechterhaltung eine Bibliothek, die benötigt   unterstützt sowohl Python 2.6 und Python   3.0, der beste Ansatz ist, indem Sie die 2.6 Schritt 3 oben zu ändern   Version des Quellcodes und Laufen   die 2to3 Übersetzer wieder statt   Bearbeiten der 3.0-Version der Quelle   Code.

Im Idealfall würden Sie mit einer einzigen Version am Ende, ist, dass 2.6-kompatibel und kann bis 3,0 unter Verwendung von 2to3 übersetzt werden. In der Praxis könnten Sie nicht in der Lage sein, dieses Ziel vollständig zu erreichen. Sie könnten also einige manuelle Änderungen benötigen, um es unter 3.0 zu arbeiten.

Ich würde diese Änderungen in einem Zweig halten, wie Ihre Wahl 2. Anstatt jedoch die endgültige 3.0-kompatible Version in diesem Zweig beibehalten, würde ich prüfen, die manuellen Änderungen anzuwenden vor die 2to3 Übersetzungen und setzen diese modifizierte 2.6-Code in Ihrer Branche. Der Vorteil dieser Methode wäre, dass der Unterschied zwischen diesem Zweig und dem 2,6-Stamm ziemlich klein wäre und nur von manuellen Änderungen bestehen würde, nicht die von 2to3 vorgenommenen Änderungen. Auf diese Weise sollten die einzelnen Zweige leichter zu pflegen und zusammenführen, und Sie sollten aus den künftigen Verbesserungen in 2to3 profitieren können.

Alternativ können Sie auch ein bisschen ein „wait and see“ -Ansatz. Fahren Sie mit Ihrem nur so weit zu portieren, wie Sie mit einer einzigen Version 2.6 und 2to3 Übersetzung gehen kann, und verschieben die verbleibende manuelle Änderung, bis Sie wirklich eine 3.0-Version benötigen. Vielleicht um diese Zeit, Sie brauchen keine manuellen Optimierungen mehr ...

Answer 2

Für Entwicklung, Option 3 ist zu umständlich. zwei Zweige pflegen ist der einfachste Weg, obwohl die Art und Weise, das zu tun zwischen VCSes variieren. Viele DVCS mit separaten repos glücklicher sein (mit einem gemeinsamen Vorfahren Zusammenführung zu helfen) und zentralisieren VCS wird wahrscheinlich einfacher mit zwei Zweigen zu arbeiten. Option 1 ist möglich, aber Sie können etwas verpassen zu verschmelzen und ein bisschen mehr fehleranfällig IMO.

Für den Vertrieb, würde ich Option 3 als auch, wenn möglich nutzen. Alle drei Optionen sind sowieso gültig und ich habe Variationen dieser Modelle von Zeiten zu Zeiten gesehen.

Answer 3

Ich glaube nicht, dass ich überhaupt diesen Weg nehmen würde. Es ist schmerzhaft Egal von welcher Seite man es betrachtet. Wirklich, es sei denn, es gibt starke kommerzielle Interesse an beide Versionen gleichzeitig zu halten, ist dies mehr Kopfschmerzen als Verstärkung.

Ich denke, es macht mehr Sinn für jetzt 2.x Entwicklung nur zu halten, zumindest für ein paar Monate bis zu einem Jahr. An einem gewissen Punkt in der Zeit wird es nur Zeit für eine endgültige, stabile Version für 2.x zu erklären und zu entwickeln, die nächsten ist für 3.x +

Zum Beispiel werde ich nicht auf 3.x wechseln, bis einige der wichtigsten Rahmenbedingungen diesen Weg zu gehen: PyQt, matplotlib, numpy, und einige andere. Und ich kümmere mich nicht wirklich, wenn sie irgendwann 2.x Unterstützung starten und stoppen nur für 3.x zu entwickeln, weil ich weiß, werde feststellen, dass in kurzer Zeit ich in der Lage sein würde wechseln auch auf 3.x.

Answer 4

Ich würde durch die Migration auf 2,6 beginnen, die ganz in der Nähe 3.0 Python. Man könnte sogar für 2,7 warten will, was noch näher sein wird, 3,0 bis Python.

Und dann, wenn Sie auf 2.6 migriert haben (oder 2.7), empfehle ich Sie einfach halten nur eine Version des Skripts, mit Dingen wie „wenn py3k: ... else: ...“ in den seltenen Orten, an denen es wird Pflicht. Natürlich ist es nicht die Art von Code, den wir Entwickler zu schreiben, aber dann müssen Sie sich nicht um die Verwaltung mehrerer Skripte oder Zweige oder Patches oder Ausschüttungen Sorge, das ist ein Alptraum sein wird.

Was auch immer Sie sich entscheiden, stellen Sie sicher, dass Sie gründliche Tests mit 100% Codeabdeckung haben.

Viel Glück!

Answer 5

Unabhängig davon, welche Option für die Entwicklung ausgewählt wird, könnten die meisten potenziellen Probleme mit gründlichen Unit-Tests gelindert werden, um sicherzustellen, dass die beiden Versionen Ausgabe erzeugen entsprechen. Das heißt, Option 2 scheint natürlichste mir: Anwendung Änderungen von einem Quellbaum zu einem anderen Quellbaum ist eine Aufgabe, die (meisten) Versionskontrollsysteme wurden entwickelt - warum nicht Vorteile der Werkzeuge, die sie bieten, dies zu erleichtern.

Für die Entwicklung ist es schwierig zu sagen, ohne ‚Ihr Publikum zu wissen‘. Mach Python Benutzer wahrscheinlich würde es begrüßen, die nicht zwei Kopien der Software noch für eine allgemeine Benutzerbasis zum Download sollte es wohl ‚einfach funktionieren‘.