Python-future: La nouvelle importation magique "configparser" casse le backport "configparser"

De plus, sur le dépôt de backport, les gens signalent déjà que cela ne fonctionne pas : https://bitbucket.org/ambv/configparser/issue/8/configparser-import-broken-on-py27

Pour le moment, je devais supprimer la dépendance à python-future dans configparser pour que cela fonctionne.

+1

Plus généralement, python-future ne doit pas installer de modules qui masquent d'autres modules installés IMO. La plupart des autres sont moins susceptibles d'être des problèmes, il pourrait donc être préférable de faire cela plutôt que d'ajouter une fausse dépendance.

@ambv , @Julian : Merci pour vos commentaires. J'aimerais corriger cela mais je ne vois pas encore la bonne façon de procéder. Voici les options telles que je les vois :

1. Supprimez configparser de python-future et modifiez la documentation pour recommander d'utiliser votre package configparser la place. Cela peut avoir du sens, mais pas à moins que configparser ne remplace ConfigParser sur Py2.7. Actuellement, il y a 14 échecs et 9 erreurs lors de l'exécution test_cfgparser.py sur Python 2.7.9 avec le package configparser installé après avoir remplacé import ConfigParser par import configparser as ConfigParser . Avec python-future et son simple alias configparser installé, tous les mêmes tests réussissent.
2. Modifiez setup.py dans python-future pour installer le package d'alias configparser uniquement si un module ou un package du même nom n'existe pas. L'inconvénient serait que les packages installés dépendraient de l'ordre dans lequel ils sont répertoriés dans requirements.txt . Pire encore, je crois que pip ne garantit pas l'installation des packages dans l'ordre dans lequel ils apparaissent dans requirements.txt . Si à la fois configparser et future étaient répertoriés, cela conduirait à ce que l'ensemble de packages installés par pip soit non déterministe.
3. Utilisez la fonctionnalité extras de setuptools pour prendre en charge une option d'installation telle que pip install future[without_configparser] .

Pensez-vous que le package configparser pourrait être modifié pour que la suite de tests Python 2.7.9 réussisse lors de son utilisation ? Cela me donnerait confiance en le recommandant pour un chemin de mise à niveau fluide pour le code Py2 qui utilise actuellement ConfigParser .

Avec le temps, de plus en plus de personnes utilisent directement le backport de configparser, car c'est le moyen d'utiliser la dernière API en amont (et les fonctionnalités) tout en étant sur Python 2.x.

Ainsi, je ne comprends pas vraiment la pertinence de vos tests d'échec. Si vous voulez l'ancienne API, vous utilisez l'ancien nom de module. Si vous voulez la nouvelle API, vous utilisez le nouveau nom. Il n'est plus logique de placer le ConfigParser 2.x à l'endroit où se trouve son remplaçant Python 3.

Ce serait bien d'avoir un correctif pour cela car j'ai reçu un rapport à ce sujet dans Kali https://bugs.kali.org/view.php?id=3245 et dans un système Kali Linux typique, j'ai des packages qui ont besoin à la fois de python -future et python-configparser. Sauf que ce dernier est cassé pour quiconque l'utilise sur Python 2.x à cause de ce bogue.

Donc, pour résumer, je pense que vous devriez implémenter (1) et abandonner les tests sur configparser. (2) n'est pas interdit car les packages Debian sont construits dans des environnements minimaux et python-configparser ne serait pas disponible lorsque setup.py est exécuté. (3) est possible mais cela signifie que l'API de python-future varie en fonction de la façon dont elle a été installée. Ce n'est vraiment pas une bonne idée car une distribution ne peut l'installer que d'une seule façon.

Merci! cc @sbrun

Actuellement, par exemple, Fedora corrige simplement configparser car ils ont également le backport disponible.

FWIW, je passe actuellement par des correctifs en amont que je dois fusionner avec le backport et je publierai le backport 3.5.1 de configparser demain. Quant à python-future, je pense aussi qu'il devrait implémenter (1).

Merci pour votre contribution, tout le monde !

Je suis prêt à supprimer configparser de python-future dans la v0.16. J'ai une branche en cours : https://github.com/PythonCharmers/python-future/tree/v0.16.x.

Je suis venu ici pour essayer de comprendre pourquoi ConfigParser.read_dict a cessé de fonctionner sur ma machine.

Il s'avère que l'un des packages que j'utilise a commencé en fonction de python-future (en particulier une partie de QGIS), puis j'ai été touché par ce problème car la version de ConfigParser en Python 2.7 n'implémente pas l'API complète de ConfigParser en Python 3.x.

J'ai résolu ce problème en verrouillant la version python-future du package :

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

Flake8 a récemment ajouté une dépendance au backport configparser que @ambv maintient généreusement. Certains utilisateurs ont également installé ce module qui a cassé le comportement existant, testé et documenté de Flake8. C'est un problème pour nous, et je vais maintenant commencer à ajouter de la documentation à Flake8 pour expliquer pourquoi les gens pourraient voir un problème. L'avenir sera spécifiquement mentionné pour aider les utilisateurs à éviter ce tracas.

@ sigmavirus24 Ian, vous pouvez contourner ce problème pour l'instant en fonction du backport configparser et en utilisant le formulaire from backports import configparser . Ceci a été spécifiquement implémenté pour débloquer des situations comme celles-ci :(

@ambv merci ! Je ne savais pas que je pouvais faire ça.

J'ai maintenant publié la v0.16.0, qui supprime configparser . La documentation recommande également d'utiliser le backport de Lukasz. Merci à tous pour vos retours!

Merci @edschofield !