Les développeurs de Python ont décidé d'abandonner leur infrastructure actuelle, basée sur divers outils open-source écrits en Python et auto-hébergés, pour passer aux services propriétaires proposés par Github. Cela implique de passer le code source de Mercurial à Git.
La raison fondamentale, détaillée dans le PEP 481, est la nécessité de faciliter le travail des contributeurs du projet, l'arrivée de nouveaux contributeurs, et les contributions occasionnelles (correction de typos, amélioration de doc).
L'infrastructure actuelle utilise un outillage spécifique, comme de nombreux projets majeurs d'il y a quelques années. L'outillage nécessite un apprentissage dédié, qui forme une barrière d'entrée aux nouveaux contributeurs et aux contributeurs occasionnels, et qui n'est pas réutilisable sur d'autres projets. Il n'est également pas le meilleur dans son genre, ce qui fait perdre du temps aux contributeurs réguliers, qui utilisent pour d'autres projets de meilleurs outils et s'en trouvent donc frustrés. Enfin, il nécessite une maintenance spécifique, ce qui d'une part prend du temps à certains contributeurs, et d'autre part fragilise l'infrastructure qui dépend d'un trop petit nombre de personnes.
Il a donc été proposé (et décidé) de passer à une infrastructure standard (de facto), populaire, qui ne nécessiterait pas de maintenance particulière et favoriserait les contributions au projet.
En premier lieu, un choix a été fait quant au système de gestion de code source à utiliser : les deux seuls en compétition étaient Mercurial et Git. Vu leur relative équivalence d'un point de vue technique, et vu la popularité du second (de 3 à 18 fois plus populaire), Mercurial a été abandonné et Git est devenu le système utilisé pour la copie maîtresse du code source de Python.
Ce choix fait, la plate-forme la plus populaire a été retenue : Github.
Github est connue pour l'excellence de son interface et de ses services, pour la taille de la communauté de contributeurs potentiels, mais également pour être propriétaire et pour le fait que son système de gestion de bugs « verrouille » les projets sur cette plate-forme.
Python n'utilisera pas le gestionnaire de bugs de Github. Par contre, il va utiliser son système de gestion de pull-requests, en parallèle avec une instance Phabricator pour ne pas en dépendre complètement.
# Python 3?
Posté par Spyhawk . Évalué à 2.
Outre les éléments avancées, ne peut on pas se demander si la vraie raison de l'abandon de Mercurial est le pauvre support de python 3 due à son design?
[^] # Re: Python 3?
Posté par wilk . Évalué à 2.
Qui a abandonné l'autre en premier tu veux dire ?
Est-ce que python3 ne s'abandonne pas tout seul d'ailleurs ?
GvR bosse chez Dropbox qui produit pyston qui reste focalisé sur python2 et risque fort d'être abandonné également puisqu'ils migrent finalement leur partie critique en Go…
GvR s'intéresse de plus en plus au typage statique.
« What did you work on for your Hack Week project?
Static typing for Python. »
« Why did you choose static typing for your project?
I think that at least adding static typing as an optional part of Python is a good thing for the distant future. I also think that this particular tool may be able to help Dropbox convert our own Python 2-based codebase to Python 3. »
J'ai l'impression, et je le constate sur mes projets perso, que les migrations de versions sont vraiment LE problème des langages dynamiques.
[^] # Re: Python 3?
Posté par Antoine . Évalué à 6.
Ce n'est rien à voir avec l'aspect dynamique du langage, juste avec le fait que le langage a décidé de casser la compatibilité à un moment donné.
S'imaginer que ça se passerait mieux avec C++ ou Ada me paraît illusoire.
Quant à Python 3, il est de plus en plus utilisé.
[^] # Re: Python 3?
Posté par ckyl . Évalué à 10.
Bonne nouvelle ! Ca fait juste… sept ans et un mois qu'il est sorti.
Allez prochaine étape, d'ici 10 ans la communauté Javascript commencera peut être à réaliser que changer 100% de ses frameworks tous les deux ans et combiner les 35 outils hype du mois n'a aucun absolument intérêt :)
[^] # Re: Python 3?
Posté par Moonz . Évalué à 3.
C’est toujours préférable à la communauté Java qui s’obstine à utiliser de vieux outils bloated et pas adaptés « parce que tout le monde l’utilise » :)
[^] # Re: Python 3?
Posté par ckyl . Évalué à 10.
On veut des noms. On balance ou on balance pas !
[^] # Re: Python 3?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il vaut mieux être bloated et pas adapté que light et pas utilisé.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Python 3?
Posté par wilk . Évalué à 7.
Je ne parle pas uniquement du passage de python 2 à 3 mais du refactoring en général, c'est la seule chose qui m'est pénible en Python, du coup en règle générale je m'abstiens, et donc même punition quand je me pose la question de migrer du code vers python 3.
C'est Guido lui-même qui m'a mis la puce à l'oreille en s'intéressant de plus en plus au typage statique. Ca m'a tellement surpris que du coup j'ai essayé en Go et sur le peu de projets que j'ai démarré c'est loin d'être illusoire, au contraire je me régale à refactoriser. Ca facilite du même coup l'optimisation en ayant beaucoup moins peur de casser quelque chose.
Je ne pense pas que Dropbox ait décidé de migrer vers Go uniquement pour des problèmes de performances, tant qu'à tout réécrire il y avait d'autres solutions plus proches de python, pypy, cython etc.
Pour en revenir au schmilblick, que penses-tu de mercurial ? L'outil qui s'enterre lui-même en refusant de suivre l'évolution de ses dépendances ?
C'est inquiétant car comme le montre très bien la discussion sur le passage vers git+github, le côté social est de plus en plus important, c'est également le côté social qui a modelé Go (formatage du code, outils, multiplateforme…). Paradoxalement à ce qu'on pourrait croire par rapport à ce que j'écris c'est ce qui me fera rester en Python, je ne lâcherai pas l'écosystème Python de si tôt.
[^] # Re: Python 3?
Posté par Antoine . Évalué à 5.
Je ne connais rien du travail interne à DropBox, je ne saurais dire pourquoi ils ont réécrit du code en Go (peut-être les performances ? ou le désir de tester un nouvel outil, pour ne pas s'enfermer dans une monoculture ?).
Je consulte de temps en temps la liste de développement de Mercurial, et on y voit passer des patches pour commencer à rendre le code compatible Python 3. Ça a l'air d'être un processus assez lent, mais il est possible que d'ici quelques années ce soit fait (bien que Matt Mackall, l'auteur de Mercurial, n'aime pas Python 3… ou en tout cas ne l'aimait pas).
Mercurial s'est surtout "enterré" en ne disposant pas d'un équivalent digne de ce nom à GitHub (BitBucket est franchement moins bien). C'est, dans un sens, largement indépendant du développement de Mercurial lui-même.
Pour être honnête, je ne suis pas convaincu que le passage à GitHub profitera beaucoup à Python. Tout simplement, CPython est un logiciel assez mûr, le langage est presqu'allé au bout de ses évolutions, et maintenant c'est surtout du boulot de maintenance. Cela fait un bout de temps que je n'ai rien vu passer de très excitant.
[^] # Re: Python 3?
Posté par flan (site web personnel) . Évalué à 8.
Par expérience, on peut faire les choses à peu près proprement en Python, à condition d'avoir un peu de rigueur et des bons outils.
Je suis assez fan de PyCharm, qui fait de l'inférence de type, mais qui a parfois besoin d'aide (on lui spécifie le type).
Accessoirement, je m'oblige à ne jamais utiliser le typage dynamique quand c'est inutile (je change de variable quand le type change).
Après, je ne serais pas contre un peu de typage statique, mais le typage dynamique est parfois bien utile.
[^] # Re: Python 3?
Posté par wilk . Évalué à 2.
J'aime bien le texte de Dave Chenney :
http://dave.cheney.net/2015/03/08/simplicity-and-collaboration où il explique que la simplicité on ne peut pas l'ajouter, on ne peut l'acquérir qu'en enlevant des choses. Hors plus un langage évolue et mieux on le connaît plus on est tenté de le pousser dans ses recoins jusqu'à s'inventer son propre langage. Du coup j'essaye de plus en plus comme toi à avoir plus de rigueur sur les côtés dynamiques.
Par contre je changerai de langage plutôt que de changer d'éditeur (c'est entre autre ce qui m'avait amené à passer de java à python !).
[^] # Re: Python 3?
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Si quelqu'un peut m'expliquer en quoi Mercurial "supporte" ou pas Python ?
Pour autant que je sache, un gestionnaire de source gère des fichiers sans trop regarder ce qu'il y a dedans … en tout cas pas au point de regarder quelle version de Python est utilisé ! ? !
Du coup, qu'est ce que j'ai loupé ?
Pour info, je précise que j'utilise Mercurial pour mes projets … mais pas Python.
Merci d'avance pour vos éclaircissements.
[^] # Re: Python 3?
Posté par GuieA_7 (site web personnel) . Évalué à 4. Dernière modification le 08 janvier 2016 à 10:10.
Mercurial est lui-même écrit principalement en Python (et donc du Python 2.X, le passage en Python 3 étant sujet à débats).
# Verrouillage?
Posté par Michaël (site web personnel) . Évalué à 6.
En quoi est-ce que le système de gestion de bugs verrouille-t-il quoique ce soit? Les données sont accessibles et exploitables automatiquement par l'API JSON/HTTPS et permettent si besoin de réaliser une migration de projet. Ou bien y-a-t'il d'autres points, qui restent problématiques?
[^] # Re: Verrouillage?
Posté par Malizor . Évalué à 5.
Github peut fermer/restreindre l'accès à cette API à tout moment.
Notons tout de même que la problématique serait exactement la même si Github était libre : le soucis est qu'on a pas la main sur l'instance du service en question.
[^] # Re: Verrouillage?
Posté par Nairwolf . Évalué à 1.
Si Github était libre, on pourrait ouvrir une instance de de Github et héberger le code ici. Le problème serait donc résolu. Le souci, c'est que cela implique de gérer le serveur, alors que là, ce serait Github qui s'occuperont des problèmes de serveurs, de backups et compagnie.
[^] # Re: Verrouillage?
Posté par Tangi Colin . Évalué à 4.
si ton problème c'est d'héberger une instance de github sur ta propre machine tu peux le faire, ils ont des offres payantes qui permettent cela.
[^] # Re: Verrouillage?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Au pire ça fait du ménage dans les vieux tickets :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Verrouillage?
Posté par wilk . Évalué à 2.
Je ne comprend pas non plus, tant qu'à faire des sacrifices pour le côté social de github, autant en tirer les avantages jusqu'au bout, quitte à changer par la suite. Les alternatives à la github sont en cours non ? https://gogs.io/
[^] # Re: Verrouillage?
Posté par Antoine . Évalué à 10.
Je me disais qu'ils mangeraient leurs propres croquettes pour chien, et puis je lis sur https://try.gogs.io/ :
[^] # Re: Verrouillage?
Posté par Chuck #1 . Évalué à 10.
Gogs, encore un nom de chiotte mais ça se justifie quand on voit que ça utilise DropzoneJS et libPQ.
Cette signature est publiée sous licence WTFPL
[^] # Re: Verrouillage?
Posté par RyDroid . Évalué à 10.
Il y a aussi GitLab et Framasoft fournit une instance.
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . Évalué à 10.
D'abord, je ne pense pas qu'on puisse dire "c'est verrouillé" ou "c'est pas verrouillé" vis à vis d'une migration.
C'est plus un spectre de possibilité, allant de "c'est facile de bouger" à "c'est très couteux". L'API aide, mais si tu as rien pour recevoir les données, tu va pas loin. Et l'API, c'est juste un truc sympa pour t'éviter de faire du scrapping, qui est pas non plus du domaine de l'impossible.
Ensuite, même avec l'API, tu restes coincé sur les comptes, et malgré le fait que des choses existes (openid, saml, persona), on s'apercoit qu'au final, les entreprises préferent mettre des moyens pour que tu restes chez elles (et donc parfois avoir tes infos) que de pousser vers la décentralisation. Donc tu as une forte adhérence à ce niveau.
Et ton nouveau BT va devoir faire un mapping d'info que tu n'as peut être pas pas (email, mot de passe).
Enfin, je pense que la partie verouillage, c'est pas sur le fait de rester sur la plateforme plus que le fait que la gestion des bugs de github est des plus primitives.
Par exemple, tu ne peux pas faire des bugs privés, ce qui est pas terrible pour les failles de sécurité, et du coup, tu te retrouves avec une procédure différente pour ce genre de bugs, et une procédure moins testé, qu'est ce qui peut arriver de mal…
Autre exemple, tu ne peux pas déléguer la classification des bugs sans donner de droits de commits, dans mon souvenir, ce qui est aussi contre productif.
Et je parle que des trucs de bases, je vais même pas chercher du coté automatisation, ou finalement, tu es obligé d'avoir un login/password pour un bot, ce qui l'expose à des risques non requis, et entraine des complications.
Donc oui, github va bien pour des petits projets du dimanche, mais dés que tu grandit, tu te retrouve avec des trucs qui coincent et ou tu peux pas faire grand chose.
(et bien sur, ça reste proprio et centralisé, ce qui visiblement emmerde pas grand monde au sein du libre, et je pourrais sans doute faire un livre entier sur le sujet…)
[^] # Re: Verrouillage?
Posté par claudex . Évalué à 3.
À part les problème que de compte (qui ne sont pas solvable, à moins d'utiliser le oauth de GitHub, au moins le temps de la migration, mais si tu quitte GitHub, il y a des chances que tu ne veuille/puisse pas utiliser ce genre de fonctionnalité).
C'est vrai, mais une API REST a tendance à moins changer qu'une interface graphique, qui peut mettre ton scraping par terre sans que tu t'en rende compte (par exemple, si tu veux faire un backup).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Verrouillage?
Posté par Michaël (site web personnel) . Évalué à 5.
La phrase originale est
et j'y comprends “verrouiller” plutôt comme dans l'expression “lock in” et que justement cela a bien à faire avec la plate-forme, dans les mots de l'OP.
Ta description des limitations de GitHub est très exacte, la gestion des bugs dans GitHub est indéniablement rudimentaire. En ce qui concerne les migrations tu aussi raison: on peut s'attendre à ce qu'elles soient douloureuses. Mais ces deux choses sont indépendantes du caractère fermé ou ouvert de la plateforme, et pour être honnête, vu que toutes les informations sont exposées publiquement et proprement (sans scrapper) GitHub ne fait rien pour empêcher les gens de partir.
Le monde du logiciel libre n'a pas du tout pris le virage des réseaux sociaux (je pense que c'est l'aspect principal qui explique le succès de GitHb) ce qu'on peut regretter, mais bon aujourd'hui c'est comme ça.
[^] # Re: Verrouillage?
Posté par Stibb . Évalué à 1.
étrangement, je ne considère pas que GitHub ait réussi le coté social:
- pas d'IM ou possibilité d'envoyer un message à un developper
- pas de groupe de discussion à la IRC
- pas de fil d'actualité à la facebook ou linkedin, pour parler de l'actualité de ses projets, diffuser ses info.
[^] # Re: Verrouillage?
Posté par Michaël (site web personnel) . Évalué à 3.
Ce n'est pas super développé, mais on reçoit quand-même des messages à propos des dépôts marqués par tels et tels développeurs dans son réseau, ce qui pour moi est la fonction la plus intéressante du réseau social.
Pour ça j'utilise surtout l'adresse mail, on la trouve dans presque tous les projets – au pire dans les logs.
Pour cela il y a une bonne intégration avec Jekyll, je viens d'ailleurs d'y transférer mon blog.
[^] # Re: Verrouillage?
Posté par Spyhawk . Évalué à 8.
Heu, le côté "social" de GitHub mis en avant, c'est avant tout le côté collaboration entre développeurs que le côté "kikoolol facebook" à destination du public, et c'est tant mieux !:
- on utilise soit l'email du developpeur, ou alors on mentionne son @nom sur un ticket en rapport avec le message.
- pas de discussion générale "à la IRC", mais ici encore discussion facilité en rapport avec un ticket
- suivi des releases et tags en fil d'actualité
- collaboration entre différent projets facilitée (mention de tickets d'un autre projet qui est en rapport avec son projet par exemple), et ca c'est le gros plus par rapport à un dépôt décentralisé.
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . Évalué à 3.
Non, mais tu as le coté vitrine de la chose. Tu montres qui tu suis (ce qui est franchement un peu naze), les projets mettent en avant le nombre de contributeurs et d'étoiles, et tu as une liste de ce que tel personne a fait.
Ceci dit, github a changé son slogan maintenant "where software is built".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.