Forum Programmation.autre Forker un projet et le maintenir à jour

Posté par  .
Étiquettes :
2
16
oct.
2012

Bonjour à tous,

Mon premier message sur ce site que je suis depuis pas mal de temps (sans pour autant m'être inscrit).

Ma question est relativement simple mais n'ayant pas d'antécédents en gestion de projet, j'ai pensé que le meilleur endroit pour poser cette question serait sûrement ici :)

Prenons un cas concret : Il y a un projet qui m'intéresse (nommément, pywebsocket) et qui est une mise en oeuvre de WebSocket (client et serveur) en python, considérée comme une implémentation de référence. Le projet est en python 2.x alors que j'aimerais programmer en python 3.x. Contact pris avec les développeurs ils n'ont pas de volonté de passer leur code vers python 3.x.

L'idée serait de forker le projet, passer un coup de 2to3.py, faire des tests de couverture de code et patcher au fur et à mesure les problèmes rencontrés (le problème majeur dans la conversion de projets 2.x vers 3.x étant souvent la gestion des chaînes de caractères et du type bytes). Le problème c'est que lorsque l'on fork un projet, on le fork à un instant 't' précis.

Ma question est la suivante: À partir du moment où l'on fork un projet, existe-t-il un moyen reconnu et/ou éprouvé de porter les modifications (patchs) apportées au projet original vers le projet forké ? Ceci de manière à les faire avancées de manières relativement synchrone.

Désolé si cette question peut vous paraître bête, mais je n'ai vraiment pas la moindre idée sur la manière de procéder… si ce n'est faire le portage des patchs en mode manuel.

Questions supplémentaires :
- Dans le cas où il faille gérer cela en mode manuel comment ferait-on si le projet était vraiment énorme (ce qui n'est pas le cas ici) ?
- Comment faudrait-il procéder si je désirais ajouter des fonctionnalités au projet forké (les deux projets finissant par avancés de manière asynchrone au fil du temps, mais partageant quand même une base de code importante) ?

Au cas où cela aurait une incidence, je suis seul sur le projet (la base de code du projet original n'étant pas très importante) et j'utilise git pour ma gestion de version.

Merci beaucoup.

Alex.

  • # git

    Posté par  (site web personnel) . Évalué à 4.

    C'est faisable avec git donc surement aussi avec svn (utiliser par le projet).

    Tu clones leur repo, tu l'upload sur ton repo perso, tu le convertis en py3 et tu merges régulièrement leur code.

    Bon, si y'a vraiment trop de différence, ca va être un joyeux bordel…

  • # Rendre le projet Python3 compatible?

    Posté par  . Évalué à 6.

    Je ne suis pas un expert en python, mais dans ton cas il y aurait peut-être des parties que tu pourrais modifier dans le code original pour le rendre python3 compatible mais tout en fonctionnant toujours en python2?
    Si les développeurs acceptent tes modifications, tu minimiserais les différences entre ton fork et l'original, c'est toujours ça de gagné..
    Bon à la réflexion, pas sûr que ça aide vraiment car ils ne testeront leurs modifications à eux qu'avec python2.

  • # Quelques idées

    Posté par  (site web personnel) . Évalué à 4.

    Note : Je tiens a m'excuser de tous les anglicismes, ils concernent la manière de travailler sur un projet a plusieurs et j’espère qu'ils seront facilement compris par tout le monde.

    • Fais des tests. Le mieux serait de couvrir 100% du code, et de tester tous les cas bizarres. Quand je dis "faire des tests" ça veut dire tests unitaires, fonctionnels, tout ce qui est testable automatiquement par une machine.
    • Lorsque tu as finis tes tests, remonte les upstream. Puisque ce sont des tests, ils devraient passer avec la version actuelle
    • Une fois (et une fois seulement) que c'est fait, commence a faire tes modifications dans ta branche
    • Lorsque tu as une fonctionnalité "traduite", propose la upstream. Le plus souvent possible.
    • Une fois mergée, rebase ta branche sur l'originale, de manière a avoir le moins de changements qui n'existent que dans ton coin.
    • Et tu recommences.

    En fait, je pense que la philosophie agile ("Release early, release often") est une approche intéressante qui te permettra de ne pas te retrouver avec un fork trop loin de l'original. Le problème est l'acceptation de tous tes patchs upstream; c'est pour ça que les tests sont vitaux, pour être sur que tu ne casses rien (et pour montrer ta bonne volonté aux développeurs originaux)

    Je ne l'ai jamais fait, mais c'est comme ça que je ferais.

  • # patch queue

    Posté par  (site web personnel) . Évalué à 3.

    Si ton « fork » n'a pas pour vocation d'être intégré au projet upstream, il peut être pratique de maintenir une « patch queue ». L'idée est que tu travailles sur une copie du repo upstream sans jamais rien y committer directement. Ce que tu committes sont des patches qui sont appliqués sur le repo. Tu as donc le repo upstream et un repo qui contient des patches.

    En pratique, ça se fait avec quilt (git) ou mq (Mercurial).

    Si le but à court terme c'est d'intégrer tes changements au projet upstream, il est peut-être plus simple de maintenir une branche que tu merges manuellement de temps en temps.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Merci !

    Posté par  . Évalué à 1.

    Bonjour à tous et merci beaucoup pour vos réponses !

    gnumdk : voilà, le but c'est d'éviter le "joyeux bordel" :)

    reno : C'est effectivement une solution attrayante, mais la difficulté est que les sockets sous python 3 manipulent des octets (type bytes) alors que sous python 2 les chaines de caractères passent très bien. Je pense que ça rend le code incompatible entre les deux versions, ceci dit il faut que je me documente pour voir si cela reste possible. A priori il ne s’agirait, en gros, que de placer des encode() / decode() aux bons endroits (avec quelques subtilités sur les ord() / chr()). Mais ça reste jouable.

    rakoo : C'est très clair, et ça me plait bien. Ceci dit je n'ai pas demandé aux développeurs du projet original s'ils étaient intéressés par une version pour python 3.x, donc je ne m'étais pas posé la question de la remontée upstream. Même sans cela, ton scénario me semble facilement applicable dans les faits, même si ça demande évidemment du boulot derrière :)

    Krunch : Ah, je ne connaissais pas du tout ce système à base de patch uniquement. Ça à l'air vraiment intéressant. La question de la remontée upstream reste posée, mais j'aurais au moins découvert un nouveau système.

    Sinon, j'ai trouvé ça sur le net pendant mes recherches : A successful Git branching model. C'est intéressant à lire en tout cas, même si tel quel ça me parait être un peu "trop" pour un petit projet comme ça.

    Merci encore pour vos réponses !

  • # git-svn, 2to3

    Posté par  . Évalué à 1.

    Ton projet étant géré par svn, tu as la possibilité d'utiliser git-svn qui te permettra d'avoir ton dépôt git (que tu peux publier où tu veux) tout en pouvant te synchroniser sur le dépôt svn d'origine.

    Ensuite pour la question python 3, il y a plusieurs possibilités, voilà quelques liens utiles:
    http://getpython3.com/#resources
    http://python3porting.com/
    http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/

    A priori, la meilleure idée serait d'utiliser 2to3 dans le setup.py pour convertir automatiquement le code pour python3. Ensuite il faut corriger en amont les points qui posent problème et remonter les patchs upstream pour avoir un code qui reste en python2 mais est compatible python3 moyennant l'utilisation de 2to3.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.