Python-future: La nueva importación mágica "configparser" rompe el backport "configparser"

Creado en 16 oct. 2014  ·  13Comentarios  ·  Fuente: PythonCharmers/python-future

Hay un backport de los cambios de configparser en Python 3.x llamado simplemente "configparser". Con sus importaciones políglotas recién introducidas, su paquete podría anular el backport, por ejemplo, no será posible usar ambos juntos.

Considere agregar el backport de configparser a la lista de requisitos de python-future, lo que resolverá este problema.

Comentario más útil

Con el paso del tiempo, más y más personas usan directamente el backport de configparser, porque esa es la forma de usar la última API (y funciones) ascendente mientras aún se encuentra en Python 2.x.

Por lo tanto, realmente no entiendo la relevancia de sus pruebas fallidas. Si desea la API anterior, use el nombre del módulo anterior. Si desea la nueva API, use el nuevo nombre. Ya no tiene sentido colocar el ConfigParser 2.x en el lugar donde está su reemplazo de Python 3.

Sería bueno tener una solución para esto, ya que obtuve un informe sobre esto en Kali https://bugs.kali.org/view.php?id=3245 y en un sistema Kali Linux típico tengo paquetes que necesitan Python -futuro y python-configparser. Excepto que este último está roto para cualquiera que lo use en Python 2.x debido a este error.

Entonces, para resumir, creo que debería implementar (1) y eliminar las pruebas sobre configparser. (2) no es una opción, ya que los paquetes de Debian se construyen en entornos mínimos y python-configparser no estaría disponible cuando se ejecuta setup.py. (3) es posible, pero significa que la API de python-future varía según cómo se haya instalado. Realmente no es una buena idea ya que una distribución solo puede tenerlo instalado de una manera.

¡Gracias! cc @sbrun

Todos 13 comentarios

Además, en el repositorio de backport, la gente ya informa que esto no funciona: https://bitbucket.org/ambv/configparser/issue/8/configparser-import-broken-on-py27

Por el momento, tuve que eliminar la dependencia de python-future en configparser para que funcione.

+1

En términos más generales, python-future no debe instalar módulos que sombreen otros módulos instalados en mi opinión. Es menos probable que la mayoría de los otros sean problemas, por lo que podría ser preferible hacer eso en lugar de agregar una dependencia falsa.

@ambv , @Julian : Gracias por sus comentarios. Me gustaría arreglar esto, pero todavía no veo la forma correcta de proceder. Aquí están las opciones como yo lo veo:

  1. Elimine configparser de python-future y cambie los documentos para recomendar el uso de su paquete configparser en su lugar. Esto puede tener sentido, pero no a menos que configparser sea un reemplazo directo de ConfigParser en Py2.7. Actualmente, hay 14 fallas y 9 errores al ejecutar test_cfgparser.py en Python 2.7.9 con el paquete configparser instalado después de reemplazar import ConfigParser con import configparser as ConfigParser . Con python-future y su simple alias configparser instalado, pasan todas las mismas pruebas.
  2. Cambie setup.py en python-future para instalar el paquete de alias configparser solo si no existe un módulo o paquete con el mismo nombre. El inconveniente de esto sería que los paquetes instalados dependerían del orden en que se enumeran en requirements.txt . Peor aún, creo que pip no garantiza la instalación de paquetes en el orden en que aparecen en requirements.txt . Si se incluyeran configparser y future , el conjunto de paquetes instalados por pip no sería determinista.
  3. Use la función extras de las herramientas de configuración para admitir una opción de instalación como pip install future[without_configparser] .

¿Crees que el paquete configparser podría modificarse para que el conjunto de pruebas de Python 2.7.9 pase al usarlo? Esto me daría confianza para recomendarlo para una ruta de actualización sin problemas para el código Py2 que actualmente usa ConfigParser .

Con el paso del tiempo, más y más personas usan directamente el backport de configparser, porque esa es la forma de usar la última API (y funciones) ascendente mientras aún se encuentra en Python 2.x.

Por lo tanto, realmente no entiendo la relevancia de sus pruebas fallidas. Si desea la API anterior, use el nombre del módulo anterior. Si desea la nueva API, use el nuevo nombre. Ya no tiene sentido colocar el ConfigParser 2.x en el lugar donde está su reemplazo de Python 3.

Sería bueno tener una solución para esto, ya que obtuve un informe sobre esto en Kali https://bugs.kali.org/view.php?id=3245 y en un sistema Kali Linux típico tengo paquetes que necesitan Python -futuro y python-configparser. Excepto que este último está roto para cualquiera que lo use en Python 2.x debido a este error.

Entonces, para resumir, creo que debería implementar (1) y eliminar las pruebas sobre configparser. (2) no es una opción, ya que los paquetes de Debian se construyen en entornos mínimos y python-configparser no estaría disponible cuando se ejecuta setup.py. (3) es posible, pero significa que la API de python-future varía según cómo se haya instalado. Realmente no es una buena idea ya que una distribución solo puede tenerlo instalado de una manera.

¡Gracias! cc @sbrun

Actualmente, por ejemplo, Fedora simplemente parchea configparser ya que también tienen disponible el backport.

FWIW, actualmente estoy revisando arreglos ascendentes que necesito fusionar con el backport y lanzaré el configparser backport 3.5.1 mañana. En cuanto a python-future, también creo que debería implementar (1).

¡Gracias a todos por sus aportes!

Estoy dispuesto a eliminar configparser de python-future en v0.16. Tengo una rama en curso: https://github.com/PythonCharmers/python-future/tree/v0.16.x.

Vine aquí tratando de averiguar por qué ConfigParser.read_dict dejó de funcionar en mi máquina.

Resulta que uno de los paquetes que uso comenzó dependiendo de python-future (específicamente una parte de QGIS), y luego me encontré con este problema porque la versión de ConfigParser en Python 2.7 no implementa la API completa de ConfigParser en Python 3.x.

Resolví esto bloqueando la versión python-future del paquete:

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

Flake8 agregó recientemente una dependencia en el backport de configparser que @ambv mantiene generosamente. Algunos usuarios también tenían instalado este módulo que rompió el comportamiento existente, probado y documentado de Flake8. Este es un problema para nosotros, y ahora voy a comenzar a agregar documentación a Flake8 para explicar por qué la gente podría ver un problema. Future se mencionará específicamente para ayudar a los usuarios a evitar esta molestia.

@sigmavirus24 Ian, puede solucionar esto por ahora dependiendo del backport configparser y usando el formulario from backports import configparser . Esto se implementó específicamente para desbloquear situaciones como estas :(

@ambv gracias! No me di cuenta de que podía hacer eso.

Ahora lancé v0.16.0, que elimina configparser . Los documentos también recomiendan usar el backport de Lukasz. ¡Gracias por sus comentarios, a todos!

Gracias @edschofield!

¿Fue útil esta página
0 / 5 - 0 calificaciones