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.
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:
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.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.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!
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