Défis de développement et de distribution de Python 3

Question

Supposons que j'ai développé un utilitaire d'utilisateur final polyvalent écrit en Python. Auparavant, je n'avais qu'une version disponible qui convenait à Python après la version 2.3 ou à peu près. Il suffisait de dire, "téléchargez Python si vous en avez besoin, puis exécutez ce script". Il n’existait qu’une version du script dans le contrôle de code source (j’utilise Git) pour garder une trace de.

Avec Python 3, ce n’est plus forcément vrai. Dans un avenir prévisible, il me faudra développer simultanément deux versions différentes, une pour Python 2.x et une pour Python 3.x. Du point de vue du développement, je peux penser à quelques options:

1. Conservez deux scripts différents dans la même branche, en apportant simultanément des améliorations.
2. Conservez deux branches distinctes et fusionnez les modifications communes dans les deux sens au fur et à mesure du développement.
3. Conservez une seule version du script et insérez un fichier de correctif qui convertit le script d’une version à l’autre. Lorsque suffisamment de modifications ont été apportées pour que le correctif ne s'applique plus proprement, résolvez les conflits et créez un nouveau correctif.

Je suis actuellement penché vers l'option 3, car les deux premières impliqueraient beaucoup d'ennui propice aux erreurs. Mais l’option 3 semble confuse et mon système de contrôle de code source est censé gérer les correctifs pour moi.

Pour le conditionnement de la distribution, plusieurs options sont disponibles:

1. Proposez deux packages de téléchargement différents, l'un adapté à Python 2 et l'autre à Python 3 (l'utilisateur devra savoir pour télécharger le correct, quelle que soit sa version de Python).
2. Offre un package de téléchargement, avec deux scripts différents à l'intérieur (l'utilisateur doit savoir pour exécuter le bon).
3. Un package de téléchargement avec deux scripts spécifiques à la version et un petit chargeur de stub pouvant fonctionner dans les deux versions de Python, exécutant le script approprié pour la version de Python installée.

Encore une fois, je suis actuellement penché vers l'option 3, bien que je n'ai pas encore essayé de développer un tel chargeur de bouts.

Avez-vous d'autres idées?

Answer 1

Modifier: ma réponse initiale était basée sur l'état de 2009, avec Python 2.6 et 3.0 comme versions actuelles. Maintenant, avec Python 2.7 et 3.3, il existe d’autres options. En particulier, il est maintenant tout à fait possible d’utiliser une base de code unique pour Python 2 et Python 3.

Voir Porter le code Python 2 sur Python 3

Réponse originale:

La recommandation officielle dit:

  

Pour le portage de Python 2.5 ou 2.6 existant   code source à Python 3.0, le meilleur   la stratégie est la suivante:

     

  

1. (Prérequis :) Commencez avec une excellente couverture de test.

  

2. Port vers Python 2.6. Cela ne devrait pas être plus de travail que le port moyen   de Python 2.x à Python 2. (x + 1).   Assurez-vous que tous vos tests passent.

  

3. (Toujours en version 2.6 :) Activez le commutateur de ligne de commande -3. Cela permet   avertissements sur les fonctionnalités qui seront   supprimé (ou modification) dans 3.0. Courez votre   suite de test à nouveau, et corriger le code   vous recevez des avertissements jusqu'à ce qu'il y ait   pas d'avertissement, et tous vos tests   toujours passer.

  

4. Exécutez le traducteur source à source 2to3 sur votre arborescence de code source.   (Voir 2to3 - Python automatisé 2 à 3   traduction de code pour plus d'informations   outil.) Exécuter le résultat de la   traduction sous Python 3.0. Manuellement   résoudre les problèmes restants, résoudre   problèmes jusqu'à ce que tous les tests passent à nouveau.

  

     

Il n'est pas recommandé d'essayer d'écrire   code source qui fonctionne inchangé sous   Python 2.6 et 3.0; vous auriez à   utilisez un style de code très contorsionné,   par exemple. éviter les déclarations d'impression,   métaclasses, et bien plus encore. Si vous êtes   maintenir une bibliothèque qui doit   supporte à la fois Python 2.6 et Python   3.0, la meilleure approche consiste à modifier l’étape 3 ci-dessus en modifiant la version 2.6.   version du code source et en cours d'exécution   le traducteur 2to3 à nouveau, plutôt que   éditer la version 3.0 de la source   code.

Idéalement, vous vous retrouveriez avec une seule version compatible 2.6 et pouvant être traduite en 3.0 avec 2to3. En pratique, vous ne pourrez peut-être pas atteindre cet objectif complètement. Vous aurez donc peut-être besoin de quelques modifications manuelles pour que cela fonctionne avec la version 3.0.

Je maintiendrais ces modifications dans une branche, comme votre option 2. Toutefois, plutôt que de conserver la version finale compatible avec la version 3.0 dans cette branche, j’envisagerais d’appliquer les modifications manuelles avant avant le 2to3. traductions, et mettez ce code 2.6 modifié dans votre branche. L'avantage de cette méthode serait que la différence entre cette branche et le tronc 2.6 serait plutôt petite et ne consisterait que de modifications manuelles, et non des modifications apportées par 2to3. De cette façon, les branches distinctes devraient être plus faciles à gérer et à fusionner, et vous devriez pouvoir bénéficier des améliorations futures de 2to3.

Vous pouvez également effectuer une petite "attente et voir". approche. Procédez à votre portage uniquement dans la mesure où vous pouvez utiliser une seule version 2.6 plus une traduction 2to3, et ajustez la modification manuelle restante jusqu'à ce que vous ayez réellement besoin d'une version 3.0. Peut-être qu'à ce moment-là, vous n'aurez plus besoin d'ajustements manuels ...

Answer 2

Pour le développement, l'option 3 est trop lourde. Maintenir deux branches est le moyen le plus simple, bien que la manière de procéder varie selon les VCS. De nombreux DVCS seront plus satisfaits avec des pensions séparées (avec une ascendance commune pour aider à la fusion) et un VCS centralisé sera probablement plus facile à utiliser avec deux branches. L’option 1 est possible, mais vous risquez de manquer quelque chose à fusionner et un peu plus d’OMI source d’erreurs.

Pour la distribution, j'utiliserais aussi l'option 3 si possible. Les 3 options sont quand même valables et j’ai vu des variations sur ces modèles de temps en temps.

Answer 3

Je ne pense pas que je prendrais ce chemin du tout. C'est douloureux, quelle que soit la façon dont vous le regardez. Vraiment, à moins que les deux versions ne présentent un intérêt commercial important, il est plus tentant que de gagner.

Je pense qu'il est plus logique de continuer à développer pour la version 2.x pour le moment, au moins pour quelques mois, jusqu'à un an. À un moment donné, il sera juste temps de déclarer une version finale stable pour 2.x et de développer les suivantes pour 3.x +

Par exemple, je ne passerai pas à la version 3.x tant que certains des principaux frameworks ne seront pas utilisés: PyQt, matplotlib, numpy et quelques autres. Et cela ne me dérange pas vraiment si, à un moment donné, ils arrêtent la prise en charge de la version 2.x et commencent à développer pour la version 3.x, car je saurai que dans peu de temps, je pourrai également passer à la version 3.x.

Answer 4

Je commencerais par migrer vers la version 2.6, qui est très proche de python 3.0. Vous voudrez peut-être même attendre la version 2.7, qui sera encore plus proche de python 3.0.

Ensuite, une fois que vous avez migré vers la version 2.6 (ou 2.7), je vous suggère de ne conserver qu'une version du script, avec des éléments tels que "si PY3K: ... else: ...". dans les rares endroits où ce sera obligatoire. Bien sûr, ce n’est pas le genre de code que nous aimons écrire, mais vous n’aurez pas à vous soucier de la gestion de plusieurs scripts, branches, patchs ou distributions, ce qui sera un cauchemar.

Quel que soit votre choix, assurez-vous de disposer de tests approfondis avec une couverture de code à 100%.

Bonne chance!

Answer 5

Quelle que soit l'option de développement choisie, la plupart des problèmes potentiels pourraient être atténués par des tests unitaires approfondis, afin de garantir que les deux versions produisent des résultats correspondants. Cela dit, l'option 2 me semble la plus naturelle: appliquer les modifications d'un arbre source à un autre est une tâche (la plupart des) systèmes de contrôle de version ont été conçus pour - pourquoi ne pas tirer parti des outils qu'ils fournissent pour faciliter cela.

Pour le développement, il est difficile de dire sans "connaître votre public". Les utilisateurs de Power Python apprécieraient probablement de ne pas télécharger deux copies de votre logiciel, mais pour une base d’utilisateurs plus générale, il devrait probablement fonctionner «à la perfection».