Fabric: Erwägen Sie, den Paramiko-Anforderungs-Pin zu stoßen, sobald Paramiko 2.0.x definitiv stabil ist

Betrachten Sie vielleicht einen Zwischenzustand, in dem für ein oder zwei Veröffentlichungen das fabric setup.py sowohl paramiko>=2 als auch paramiko<2 zulässt und die Leute cryptography standardmäßig, kann aber bei Bedarf die alte Version von PyCrypto erzwingen. Sobald das ein wenig eingebrannt ist, können Sie setup.py , um paramiko>=2 zu benötigen.

Ich bin mir nicht sicher, ob ich Fabric 1.x jemals dazu bringen würde, paramiko>=2 zu benötigen, und plane, das für Fabric 2.x zu speichern. Hängt von der Aufnahme von Fabric 2.x ab, wenn es raus ist, denke ich.

Sie haben Recht, dass es immer noch lösbar ist, zu ungepinntem "Ist mir egal, Paramiko 1 oder 2 ist in Ordnung" zurückzukehren, indem Sie die Leute ihre Paramiko manuell herabstufen lassen. Das Anheften war hauptsächlich ein Versuch, eine Flut von "Onoz u brach meinen Build"-Berichten abzuwehren. Wir haben einige bekommen, aber nicht eine Tonne, ob das an meiner Nadel lag oder nicht, kann niemand vermuten.

@bitprophet FWIW, ich habe einige Daten! In den letzten 2 Wochen (also ein paar Tage vor der eigentlichen Veröffentlichung von Paramiko 2.0) sind hier die am häufigsten heruntergeladenen Paramiko-Versionen von PyPI:

| Version | Downloads |
| --- | --- |
| 1.16.0 | 411903 |
| 2.0.0 | 308131 |
| 1.17.0 | 77360 |
| 1.15.2 | 47677 |
| 1.15.1 | 23893 |

Für mich bedeutet diese sehr große Anzahl von 2.0-Installationen, dass es wahrscheinlich sicher ist, und daher ist es unnötig, die <2 Grenze zu entfernen, für die meisten Leute wird es gut funktionieren (oder leicht behoben werden) und für diejenigen, die es können nicht einfach pip install paramiko<2 bevor pip install fabric das Problem beheben wird.

Wäre es zumindest möglich, einen Umgebungsmarker zu verwenden, um Fabric zu sagen, dass er zumindest paramiko>2 für PyPy verwenden soll, wo der aktuelle Status quo ist, dass Fabric sowieso nicht installiert wird?

@alex verspätet <2 Grenze ist sicher"? (statt "unnötig") :D

@Julian Ich nehme an, du meinst noch ein paar Zeilen " install_requires basierend auf dem aktuellen Interpreter"? Dem nicht ohne weiteres entgegen. (Obwohl IIRC solche Hacks aufhören, mit Rädern zu arbeiten, also fangen wir an, sie zu scheuen ...?)

Ähhh, ja, ich meinte, es ist sicher.

@bitprophet für Räder machst du dasselbe, nur in extras_require mit einem Umgebungsmarker.

Im Grunde reibt man @dstuffts Bauch und ein

(Schwerwiegenderes Beispiel: https://github.com/Julian/jsonschema/blob/master/setup.py#L25, aber Sie ersetzen python_version durch python_interpreter , um stattdessen darauf zu versenden).

Ich werde versuchen, das in eine PR zu packen, damit Sie sehen können, wie es aussieht, es sei denn, Sie sind dabei, dies so oder so zu realisieren?

Oh schön, ich erinnere mich nur vage daran, vor einiger Zeit etwas über dieses Zeug zu erfahren. Dann klar vergessen. Ich bin definitiv nicht dabei, das zu tun, wenn es einigen Leuten hilft und der Mehrheit nicht schadet. Eine PR wäre wünschenswert.

Re: Äußeres Problem, ich denke, an dieser Stelle bin ich damit fertig, den Pin in Fabric 1.12+ auf <3 zu stoßen (neben den anderen zuvor erwähnten Crypto-Bereinigungen, obwohl sie bedingt werden müssten, es sei denn, ich wollte es) tun paramiko>=2,<3 , was ich weniger befürworte.Werde sehen, wie hässlich die Dinge werden, wenn ich das anstecke und versuche sicherzustellen, dass der gleiche Fabric-Zweig die Tests in zwei separaten Venvs besteht, einem mit Crypto und Paramiko 1, dem andere ohne Crypto und Paramiko 2)

Hallo Leute

Kleine Ergänzung zu dieser Diskussion:
Wir verwenden Macports , um den Fabric-Port zu installieren, der vom Paramiko-Port auf unseren macOS-Workstations abhängt.
Aber vor kurzem hat Macports beschlossen, Paramiko von Version 1.16.0 auf 2.0.1 zu

➜ 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

Ich habe um ihn herum durch die Herabstufung paramiko auf Version 1.16.0 mit Macports, die ein bisschen von Hand zu tun war kompliziert, aber schließlich wurde es wieder zu arbeiten.

Ich denke, dies ist ein Fehler von Macports, sie hätten warten sollen, um Paramiko in ihrem Baum zu aktualisieren, bis Fabric kompatibel war.

Aber wie auch immer, es wäre großartig, wenn eine neue Version von Fabric mit Unterstützung für Paramiko > 2.0 veröffentlicht werden könnte, damit wir alles wieder zum Laufen bringen können, indem wir Macports mit den neuesten Versionen aller Ports verwenden.

Grump, das nervt - danke für die Nachricht, @hostep. (Ich will nicht bissig sein, aber - auch überrascht, dass MacPorts immer noch im Einsatz ist, jeder, den ich kenne, ist vor Jahren auf Homebrew umgestiegen. Gute Erinnerung daran, dass "top of mind" ! = "das einzige Spiel in der Stadt" ich denke :))

Ich habe gestern Abend aus einer Laune heraus eine winzige 1.12 herausgebracht (eine weitere gute Erinnerung an mich selbst: Hören Sie auf, wörtliche Versionsnummern zu verwenden, wenn Sie über die Roadmap sprechen - sagen Sie einfach "eine bevorstehende Feature-Version" oder usw.) und habe diese Änderung nicht vorgenommen, möchte es aber trotzdem tun Sie es bald, also wahrscheinlich die nächste Nebenversion.

FWIW, wir (FreeBSD) hatten das gleiche Problem und mussten eine paramiko1-Portierung und ein Paket erstellen, auf das py-fabric angewiesen ist. Siehe auch:

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

TLDR: <= und == Abhängigkeiten sind super schmerzhaft/ärgerlich und schaffen mehr Probleme, als sie vorgeben zu lösen.

Downstream-Benutzer und Paketierer/Portierer haben viel weniger Schmerzen, wenn Upstreams nur proaktiv die neuesten Versionen ihrer Abhängigkeiten testen (in der Entwicklung ist dies vor der Veröffentlichung der beste Zeitpunkt) und die Versionsverwaltung der Abhängigkeiten nicht vorschreiben oder einschränken, es sei denn es gibt Versionen, die explizit die Kompatibilität unterbrechen.

Selbst in diesem Fall ist die Einschränkung nur vorübergehend und nur dann, wenn eine Veröffentlichung erstellt wird, während sie defekt ist, und nur während der/die Autor(en) der Abhängigkeiten benachrichtigt werden und bis Korrekturen vorgenommen werden.

Der Vorteil dieser Methode ist, dass sie Upstreams (und Upstreams von Upstreams) beibringt, dass die Entscheidungen, die sie treffen, ihre Benutzer tatsächlich in der Praxis (nicht nur in der Theorie) beeinflussen, und mit diesem Wissen hoffentlich die Wahrscheinlichkeit minimiert, dass dies in Zukunft wieder passiert.

Um ein bisschen mehr Informationen zum Macports-Problem hinzuzufügen, scheint es behoben zu sein, da während der Installation ein Patch hinzugefügt wurde, der die Anforderung für Paramiko von <2.0 auf <3.0 ändert
Wir führen jetzt Fabric v1.12.0 & Paramiko v2.0.2 auf unseren macOS-Workstations aus und haben damit keine Probleme.

@hostep Danke, dass du das hervorgehoben hast

@hostep Tatsächlich habe ich manchmal *_requires Spezifikationen (von <= / == bis >= oder '' ) in FreeBSD überschrieben Ports, wenn die Testsuite mit einer neueren Version der Abhängigkeit bestanden hat. Dies hängt jedoch von der Großartigkeit der Tests ab und kann daher riskant sein, und obwohl wir Fabric nachgelagert sind, möchten wir unsere Benutzerumgebungen (nachgelagerte Umgebungen) auch nicht kaputt machen :)

Weitere Zahlenaktualisierungen...Übersicht der letzten 6 Monate:

und letzte 2 Wochen:

Paramiko 2.0.x jetzt locker die Hälfte aller Downloads. Und ich frage mich, wie viel von den anderen 50% darauf zurückzuführen ist, dass dieses Ticket nicht zusammengeführt wird :) wird es bald herausfinden!

Denke, ich werde das ausführen und es als Fab 1.13.0 herausgeben.

Ich habe noch einmal nachgesehen, was langer Zeit besprochen haben, aber dass extras_require Magie nur notwendig scheint, wenn ich die Änderung auf PyPy beschränken wollte; An dieser Stelle mache ich nur das "Paramiko <3 zulassen"-Bit im Großhandel ...

Es gibt PyPI

Gah, natürlich habe ich das Geschwisterticket vergessen, Nr. 1462! 1.13.1 unterwegs...EDIT: und, zusammengeführt/freigegeben.

Hurra!

Am 9. Dezember 2016, 20:14 Uhr, schrieb "Jeff Forcer" [email protected] :

Gah, natürlich habe ich das Geschwisterticket vergessen, #1462
https://github.com/fabric/fabric/pull/1462 ! 1.13.1 unterwegs...

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fabric/fabric/issues/1461#issuecomment-266111875 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAUIXlbJBlS0po_zKgQsUp7-y7I7WgbTks5rGbajgaJpZM4ITeNm
.