Fabric: Envisagez de remplacer la broche d'exigence de Paramiko une fois que Paramiko 2.0.x est définitivement stable

Considérez peut-être un état intermédiaire, où pour une ou deux versions, le fabric setup.py autorise à la fois paramiko>=2 et paramiko<2 , et les gens obtiendront cryptography par défaut, mais peut forcer l'ancienne version PyCrypto s'ils en ont besoin. Une fois que cela est un peu brûlé, vous pouvez déplacer setup.py pour exiger paramiko>=2 .

Je ne suis pas sûr de faire en sorte que Fabric 1.x nécessite paramiko>=2, je prévois de l'enregistrer pour Fabric 2.x. Dépend de l'adoption de Fabric 2.x une fois qu'il est sorti, je suppose.

Vous avez raison, il est toujours possible de revenir à "Je m'en fiche, le paramiko 1 ou 2 est ok" en laissant les gens rétrograder manuellement leur Paramiko. l'épinglage était principalement une tentative d'éviter un flot de rapports "onoz tu a cassé ma construction". Nous en avons eu, mais pas une tonne, que cela soit dû à mon épingle ou non, personne ne le devine.

@bitprophet FWIW, j'ai quelques dataz ! Au cours des 2 dernières semaines (cela inclut donc quelques jours avant la sortie de paramiko 2.0), voici les versions de Paramiko les plus téléchargées de PyPI :

| Versions | Téléchargements |
| --- | --- |
| 1.16.0 | 411903 |
| 2.0.0 | 308131 |
| 1.17.0 | 77360 |
| 1.15.2 | 47677 |
| 1.15.1 | 23893 |

Pour moi, ce très grand nombre d'installations 2.0 indique que c'est probablement sûr, et donc supprimer la limite <2 est inutile, pour la plupart des gens cela fonctionnera très bien (ou sera facilement corrigé), et pour ceux qui peuvent Ne faites pas simplement un pip install paramiko<2 avant que pip install fabric le répare.

Serait-il possible d'utiliser au moins un marqueur d'environnement pour dire à Fabric d'utiliser au moins paramiko>2 pour PyPy, où le statu quo actuel est que Fabric ne s'installera pas de toute façon ?

@alex tardivement, vouliez-vous dire "la suppression de la limite <2 est sûre" ? (au lieu de "inutile") :D

@Julian Je suppose que vous voulez dire encore quelques lignes de "modifier install_requires fonction de l'interpréteur actuel" ? Pas opposé à cela désinvolte. (Bien que ces hacks de l'IIRC cessent de fonctionner avec des roues, nous commençons donc à nous en éloigner... ?)

Euh, oui, je voulais dire que c'est sûr.

@bitprophet pour les roues, vous faites la même chose, juste en extras_require avec un marqueur d'environnement.

En gros, vous frottez le ventre de @dstufft et un génie en sort.

(Exemple plus sérieux : https://github.com/Julian/jsonschema/blob/master/setup.py#L25 mais vous remplacez python_version par python_interpreter pour envoyer à la place).

Je vais essayer de mettre cela dans un PR afin que vous puissiez voir à quoi cela ressemble, à moins que vous ne soyez sur le point de faire en sorte que cela se produise de toute façon?

Oh chouette, je ne me souviens que vaguement d'avoir appris ce genre de choses il y a quelque temps. Clairement alors oublié. Je suis définitivement prêt à le faire si cela peut aider certaines personnes et ne pas nuire à la majorité. Un RP serait apprécié.

Re: problème externe, je pense qu'à ce stade, je suis en train de faire passer la broche à <3 dans Fabric 1.12+ (à côté des autres purges Crypto mentionnées précédemment, bien qu'elles devraient devenir conditionnelles à moins que je ne le veuille faire paramiko>=2,<3 , ce que je suis moins en faveur. Je verrai à quel point les choses deviennent laides quand je le pousse et essaie de m'assurer que la même branche Fabric réussit les tests dans deux venv distincts, l'un avec Crypto et Paramiko 1, le autre sans Crypto et Paramiko 2)

salut les gars

Petit ajout à cette discussion :
Nous utilisons Macports pour installer le port Fabric qui dépend du port Paramiko sur nos postes de travail macOS.
Mais récemment, Macports a décidé de mettre à exécutons maintenant Fabric, cela ne fonctionne plus :

➜ fab deploy
Traceback (most recent call last):
  File "/opt/local/bin/fab", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2927, in <module>
    <strong i="13">@_call_aside</strong>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2913, in _call_aside
    f(*args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2940, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 637, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 650, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 829, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'paramiko<2.0,>=1.10' distribution was not found and is required by Fabric

J'ai contourné le problème en rétrogradant Paramiko à la version 1.16.0 à l'aide de Macports, ce qui était un peu compliqué à faire manuellement, mais a finalement réussi à le faire fonctionner à nouveau.

Je pense que c'est une erreur de Macports, ils auraient dû attendre pour mettre à niveau Paramiko dans leur arbre jusqu'à ce que Fabric soit compatible.

Mais de toute façon, ce serait formidable si une nouvelle version de Fabric pouvait être publiée avec la prise en charge de Paramiko > 2.0 afin que nous puissions tout faire fonctionner à nouveau en utilisant Macports avec les dernières versions de tous les ports.

Grump, c'est ennuyeux - merci pour les nouvelles, @hostep. (Je n'essaie pas d'être sarcastique, mais - également surpris que MacPorts soit toujours utilisé, tout le monde que je connais est passé à Homebrew il y a des années. Bon rappel que "top of mind" ! = "le seul jeu en ville" je suppose :))

J'ai sorti un petit 1.12 sur un coup de tête hier soir (un autre bon rappel à moi-même : arrêtez d'utiliser les numéros de version littéraux lorsque vous discutez de la feuille de route - dites simplement "une version de fonctionnalité à venir" ou etc.) et n'ai pas fait ce changement, mais je veux toujours faites-le bientôt, donc probablement la prochaine version mineure à la place.

FWIW, nous (FreeBSD) avons rencontré le même problème et avons dû créer un port paramiko1 et un package sur lesquels py-fabric dépendre. Voir également:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213893
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214379

TLDR : <= et == les dépendances sont très douloureuses/ennuyeuses et créent plus de problèmes qu'elles ne prétendent en résoudre.

Il y a beaucoup moins de douleur pour les utilisateurs en aval et les emballeurs/porteurs lorsque les amonts testent simplement de manière proactive les dernières versions de leurs dépendances (en développement, avant les versions est le meilleur moment pour le faire) et ne prescrivent ou ne contraignent pas le versioning des dépendances à moins que il existe des versions qui rompent explicitement la compatibilité.

Même dans ce cas, la limitation n'est que temporaire, et seulement si une version est faite alors qu'elle est cassée, et seulement pendant que le ou les auteurs des dépendances sont notifiés et jusqu'à ce que des correctifs soient apportés.

L'avantage de cette méthode est qu'elle enseigne aux amonts (et aux amonts des amonts) que les décisions qu'ils prennent affectent réellement leurs utilisateurs dans la pratique (pas seulement en théorie), et avec cette connaissance, minimise, espérons-le, la probabilité que cela se reproduise à l'avenir.

Pour ajouter un peu plus d'informations concernant le problème Macports, il semble être résolu car ils ont ajouté un correctif lors de l'installation qui modifie la configuration requise pour Paramiko de <2.0 à <3.0
Nous exécutons maintenant Fabric v1.12.0 et Paramiko v2.0.2 sur nos postes de travail macOS et n'avons aucun problème avec cela.

@hostep Merci de l'avoir souligné

@hostep En effet, il y a des moments où j'ai remplacé les spécifications de *_requires (de <= / == à >= ou '' ) dans FreeBSD ports, si la suite de tests a réussi avec une version ultérieure de la dépendance. Cependant, cela repose sur l'impressionnant des tests et peut donc être risqué, et bien que nous soyons en aval de Fabric, nous n'aimons pas non plus casser nos environnements utilisateur (en aval) :)

Plus de mises à jour de chiffres... aperçu des 6 derniers mois :

et dernières 2 semaines :

Paramiko 2.0.x maintenant facilement la moitié de tous les téléchargements. Et je me demande combien des 50% restants sont dus au fait que ce ticket n'est pas fusionné :) je le découvrirai bientôt !

Je pense que je vais l'exécuter et le sortir en tant que Fab 1.13.0.

Revisité de ce que @Julian et moi avons discuté il y a extras_require ne semble nécessaire que si je voulais limiter le changement à PyPy; à ce stade, je fais juste le bit "autoriser Paramiko <3" en gros ...

Il y a PyPI

Gah, bien sûr que j'ai oublié le ticket frère, #1462 ! 1.13.1 en route... EDIT : et, fusionné/publié.

Hourra !

Le 9 décembre 2016 à 20h14, "Jeff Forcier" [email protected] a écrit :

Gah, bien sûr j'ai oublié le ticket frère, #1462
https://github.com/fabric/fabric/pull/1462 ! 1.13.1 en route...

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fabric/fabric/issues/1461#issuecomment-266111875 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAUIXlbJBlS0po_zKgQsUp7-y7I7WgbTks5rGbajgaJpZM4ITeNm
.