Python-future: Der neue magische „configparser“-Import unterbricht den „configparser“-Backport

Erstellt am 16. Okt. 2014  ·  13Kommentare  ·  Quelle: PythonCharmers/python-future

Es gibt einen Backport der Configparser-Änderungen in Python 3.x, der einfach "configparser" genannt wird. Mit Ihren neu eingeführten polyglotten Importen überschreibt Ihr Paket möglicherweise den Backport, z. B. wird es nicht möglich sein, beide zusammen zu verwenden.

Bitte erwägen Sie, den configparser-Backport zur Liste der Anforderungen von python-future hinzuzufügen, wodurch dieses Problem gelöst wird.

Hilfreichster Kommentar

Mit der Zeit verwenden immer mehr Personen direkt den Configparser-Backport, da dies der Weg ist, die neueste Upstream-API (und Funktionen) zu verwenden, während sie immer noch auf Python 2.x sind.

Daher verstehe ich die Relevanz Ihrer fehlgeschlagenen Tests nicht wirklich. Wenn Sie die alte API möchten, verwenden Sie den alten Modulnamen. Wenn Sie die neue API möchten, verwenden Sie den neuen Namen. Es macht keinen Sinn mehr, den 2.x ConfigParser dort zu platzieren, wo sein Python 3-Ersatz ist.

Es wäre schön, eine Lösung dafür zu haben, da ich einen Bericht darüber in Kali https://bugs.kali.org/view.php?id=3245 erhalten habe und in einem typischen Kali-Linux-System habe ich Pakete, die beide Python benötigen -future und python-configparser. Abgesehen davon, dass letzteres aufgrund dieses Fehlers für alle, die es unter Python 2.x verwenden, kaputt ist.

Um es zusammenzufassen, denke ich, dass Sie (1) implementieren und die Tests über configparser fallen lassen sollten. (2) ist kein No-Go, da Debian-Pakete in minimalen Umgebungen erstellt werden und python-configparser nicht verfügbar wäre, wenn setup.py ausgeführt wird. (3) ist möglich, aber es bedeutet, dass die API von python-future je nach Installation variiert. Es ist wirklich keine gute Idee, da eine Distribution es nur auf eine Weise installieren kann.

Danke! cc @sbrun

Alle 13 Kommentare

Auch im Backport-Repo berichten die Leute bereits, dass dies nicht funktioniert: https://bitbucket.org/ambv/configparser/issue/8/configparser-import-broken-on-py27

Vorerst musste ich die Abhängigkeit von python-future im configparser entfernen, damit es funktioniert.

+1

Allgemeiner gesagt sollte python-future keine Module installieren, die andere installierte Module IMO beschatten. Bei den meisten anderen handelt es sich wahrscheinlich weniger um Probleme, daher ist es möglicherweise vorzuziehen, dies einfach zu tun, anstatt eine falsche Abhängigkeit hinzuzufügen.

@ambv , @Julian : Danke für dein Feedback. Ich würde das gerne beheben, sehe aber noch nicht die richtige Vorgehensweise. Hier sind die Optionen, wie ich es sehe:

  1. Entfernen Sie configparser aus python-future und ändern Sie die Dokumentation, um stattdessen die Verwendung Ihres configparser -Pakets zu empfehlen. Dies mag sinnvoll sein, aber nicht, es sei denn, configparser ist ein Drop-in-Ersatz für ConfigParser auf Py2.7. Derzeit gibt es 14 Fehler und 9 Fehler, wenn test_cfgparser.py unter Python 2.7.9 ausgeführt wird und das Paket configparser installiert ist, nachdem import ConfigParser durch import configparser as ConfigParser ersetzt wurde. Wenn python-future und sein einfacher configparser -Alias ​​installiert sind, werden alle Tests bestanden.
  2. Ändern Sie setup.py in python-future so, dass das Alias-Paket configparser nur installiert wird, wenn kein Modul oder Paket mit demselben Namen vorhanden ist. Der Nachteil dabei wäre, dass die installierten Pakete von der Reihenfolge abhängen würden, in der sie in requirements.txt aufgeführt sind. Schlimmer noch, ich glaube, pip garantiert nicht, dass Pakete in der Reihenfolge installiert werden, in der sie in requirements.txt erscheinen. Wenn sowohl configparser als auch future aufgelistet wären, würde dies dazu führen, dass die von pip installierten Pakete nicht deterministisch wären.
  3. Verwenden Sie die Funktion extras der Setuptools, um eine Installationsoption wie pip install future[without_configparser] zu unterstützen.

Denken Sie, dass das configparser -Paket so modifiziert werden könnte, dass die Python 2.7.9-Testsuite besteht, wenn es verwendet wird? Dies würde mir das Vertrauen geben, es für einen reibungslosen Upgrade-Pfad für Py2-Code zu empfehlen, der derzeit ConfigParser verwendet.

Mit der Zeit verwenden immer mehr Personen direkt den Configparser-Backport, da dies der Weg ist, die neueste Upstream-API (und Funktionen) zu verwenden, während sie immer noch auf Python 2.x sind.

Daher verstehe ich die Relevanz Ihrer fehlgeschlagenen Tests nicht wirklich. Wenn Sie die alte API möchten, verwenden Sie den alten Modulnamen. Wenn Sie die neue API möchten, verwenden Sie den neuen Namen. Es macht keinen Sinn mehr, den 2.x ConfigParser dort zu platzieren, wo sein Python 3-Ersatz ist.

Es wäre schön, eine Lösung dafür zu haben, da ich einen Bericht darüber in Kali https://bugs.kali.org/view.php?id=3245 erhalten habe und in einem typischen Kali-Linux-System habe ich Pakete, die beide Python benötigen -future und python-configparser. Abgesehen davon, dass letzteres aufgrund dieses Fehlers für alle, die es unter Python 2.x verwenden, kaputt ist.

Um es zusammenzufassen, denke ich, dass Sie (1) implementieren und die Tests über configparser fallen lassen sollten. (2) ist kein No-Go, da Debian-Pakete in minimalen Umgebungen erstellt werden und python-configparser nicht verfügbar wäre, wenn setup.py ausgeführt wird. (3) ist möglich, aber es bedeutet, dass die API von python-future je nach Installation variiert. Es ist wirklich keine gute Idee, da eine Distribution es nur auf eine Weise installieren kann.

Danke! cc @sbrun

Derzeit patcht beispielsweise Fedora einfach den Configparser, da sie auch den Backport zur Verfügung haben.

FWIW, ich gehe derzeit Upstream-Korrekturen durch, die ich zum Backport zusammenführen muss, und werde morgen den Configparser-Backport 3.5.1 veröffentlichen. Was python-future betrifft, denke ich auch, dass es (1) implementieren sollte.

Danke für euren Input, alle!

Ich bin bereit, configparser aus python-future in v0.16 zu entfernen. Ich habe eine Verzweigung in Arbeit: https://github.com/PythonCharmers/python-future/tree/v0.16.x.

Ich kam hierher, um herauszufinden, warum ConfigParser.read_dict aufgehört hat, an meinem Rechner zu arbeiten.

Es stellte sich heraus, dass eines der von mir verwendeten Pakete abhängig von python-future (insbesondere einem Teil von QGIS) gestartet wurde, und dann wurde ich von diesem Problem getroffen, weil die Version von ConfigParser in Python 2.7 nicht die vollständige API von ConfigParser implementiert in Python 3.x.

Ich habe dies gelöst, indem ich die python-future -Version des Pakets gesperrt habe:

sudo chmod 000 /usr/lib/python2.7/dist-packages/configparser/

Flake8 hat kürzlich eine Abhängigkeit vom Configparser-Backport hinzugefügt, die @ambv großzügig pflegt. Einige Benutzer hatten dieses Modul auch installiert, wodurch das bestehende, getestete und dokumentierte Verhalten von Flake8 unterbrochen wurde. Dies ist ein Problem für uns, und ich werde jetzt anfangen, Dokumentation zu Flake8 hinzuzufügen, um zu erklären, warum Leute ein Problem sehen könnten. Future wird speziell erwähnt, um den Benutzern zu helfen, diesen Ärger zu vermeiden.

@sigmavirus24 Ian, Sie können dies vorerst umgehen, indem Sie sich auf den configparser -Backport verlassen und das from backports import configparser -Formular verwenden. Dies wurde speziell implementiert, um Situationen wie diese zu entsperren :(

@ambv danke! Ich wusste nicht, dass ich das kann.

Ich habe jetzt v0.16.0 veröffentlicht, das configparser entfernt. Die Dokumentation empfiehlt auch die Verwendung von Lukasz's Backport. Danke für euer Feedback, alle!

Danke @edschofield!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen