Fabric: Considere golpear el pin de requisito de Paramiko una vez que Paramiko 2.0.x sea definitivamente estable

Creado en 30 abr. 2016  ·  19Comentarios  ·  Fuente: fabric/fabric

  • Publicamos 1.10.3 y 1.11.1 con fijación explícita de paramiko<2 para evitar que los entornos de las personas se actualicen / rompan inesperadamente, hace un tiempo.
  • Paramiko 2.0 ya está disponible, pero es nuevo, presumiblemente podrían ser algunos errores que deben solucionarse.
  • Sería agradable permitir que las personas se actualicen a Paramiko 2.0 en Fabric 1 si lo desean explícitamente; sin embargo, no veo una forma en setuptools / pip para hacer esto

    • por ejemplo, la funcionalidad extras_require no le permite anular el mismo paquete / versión que se especifica en install_requires , por lo que no podemos hacer pip install fabric[paramiko-2] ni nada.

    • Con suerte, hay algo más que podamos hacer que me falta, como los parámetros setup.py CLI, pero tampoco son una panacea, ya que no funcionan con ruedas ni con ningún otro método de instalación que no sea sdist.

    • También me gustaría evitar tener que hacer una segunda entrada PyPI terrible / setup.py como fabric-paramiko2 aunque esa es otra opción.

  • Dado que Paramiko 2 es compatible con API con Paramiko 1, _may_queremos simplemente subir el pin de la versión a paramiko<3 en versiones posteriores de Fabric, para que la gente pueda continuar recibiendo correcciones de errores / seguridad / etc. de la línea Paramiko 2.x

    • Si hacemos esto, necesitamos eliminar la llamada Crypto.atfork en decorators.py (ver # 1460) y asegurarnos de que no quede ningún otro equipaje de PyCrypto

    • Esto todavía tendrá la posibilidad de romperse para las personas que no pueden obtener la rueda estática todo en uno Cryptography.io; actualizarán Fabric y luego explotará si carecen de libffi-dev o openssl-dev. Por lo tanto, sería completamente sensato no deshacer nunca este pin, sino que la gente use Fabric 2 una vez que esté fuera.

Packaging Support

Comentario más útil

Grump, eso es molesto, gracias por la noticia, @hostep. (No estoy tratando de ser sarcástico, pero también me sorprende que MacPorts todavía esté en uso, todos los que conozco se cambiaron a Homebrew hace años. ¡Un buen recordatorio de que "top of mind"! = "El único juego en la ciudad", supongo :))

Anoche saqué un pequeño 1.12 por capricho (otro buen recordatorio para mí mismo: deje de usar números de versión literales cuando discuta la hoja de ruta, solo diga "una próxima versión de función", etc.) y no hice este cambio, pero aún así quiero hazlo pronto, así que probablemente la próxima versión menor.

Todos 19 comentarios

Quizás considere un estado intermediario, donde para uno o dos lanzamientos, el fabric setup.py permite tanto paramiko>=2 como paramiko<2 , y la gente obtendrá cryptography por defecto, pero puede forzar la versión antigua PyCrypto si la necesitan. Una vez que se haya quemado un poco, puede mover setup.py para requerir paramiko>=2 .

No estoy seguro de si alguna vez haría que Fabric 1.x requiera paramiko> = 2, planeando guardar eso para Fabric 2.x. Depende de la adopción de Fabric 2.x una vez que esté disponible, supongo.

Tienes razón en que volver a "No me importa, paramiko 1 o 2 está bien" sin fijar todavía se puede resolver permitiendo que la gente rebaje manualmente su Paramiko. la fijación fue principalmente un intento de evitar una avalancha de informes de "onoz u rompió mi construcción". Hemos conseguido algunos, pero no una tonelada, aunque nadie sabe si se debió a mi pin o no.

@bitprophet FWIW, ¡tengo algunos datos! Durante las últimas 2 semanas (por lo que esto incluye unos días antes de que se lanzara realmente paramiko 2.0), aquí están las versiones de Paramiko más descargadas de PyPI:

| Versión | Descargas |
| --- | --- |
| 1,16,0 | 411903 |
| 2.0.0 | 308131 |
| 1,17,0 | 77360 |
| 1.15.2 | 47677 |
| 1.15.1 | 23893 |

Para mí, esta gran cantidad de instalaciones 2.0 indica que probablemente sea seguro, por lo que eliminar el límite <2 es innecesario, para la mayoría de las personas funcionará bien (o se solucionará fácilmente) y para aquellos que pueden No es simplemente hacer un pip install paramiko<2 antes de que pip install fabric lo arregle.

¿Sería posible al menos usar un marcador de entorno para decirle a fabric que use paramiko> 2 para PyPy al menos, donde el status quo actual es que fabric no se instalará de todos modos?

@alex tardíamente, ¿quiso decir "eliminar el límite <2 es seguro"? (en lugar de "innecesario"): D

@Julian Supongo que te refieres a otras pocas líneas de "alterar install_requires según el intérprete actual". No me opongo a eso de improviso. (Aunque IIRC, tales hacks dejan de funcionar con ruedas, ¿estamos empezando a alejarnos de ellos ...?)

Uhhh, sí, quise decir que es seguro.

@bitprophet para ruedas haces lo mismo, solo en extras_require con un marcador de entorno.

Básicamente, frotas la barriga de

(Ejemplo más serio: https://github.com/Julian/jsonschema/blob/master/setup.py#L25 pero reemplaza python_version con python_interpreter para enviar en su lugar).

Intentaré poner eso en un PR para que pueda ver cómo se ve, a menos que esté a punto de hacer que esto suceda de cualquier manera.

Oh, genial, solo recuerdo vagamente haber aprendido sobre esas cosas hace un tiempo. Claramente luego se olvidó. Definitivamente estoy dispuesto a hacer eso si ayuda a algunas personas y no daña a la mayoría. Se agradecería un PR.

Re: problema externo, creo que en este punto estoy dispuesto a cambiar el pin a <3 en Fabric 1.12+ (junto con las otras purgas de Crypto mencionadas anteriormente, aunque tendrían que convertirse en condicionales a menos que yo quisiera do paramiko>=2,<3 , por lo que estoy menos a favor. Veré lo feas que se ponen las cosas cuando pinche esto y trate de asegurarme de que la misma rama de Fabric pase las pruebas en dos venvs separados, uno con Crypto y Paramiko 1, el otro sin Crypto y Paramiko 2)

Hola tios

Pequeña adición a esta discusión:
Usamos Macports para instalar el puerto Fabric, que depende del puerto Paramiko en nuestras estaciones de trabajo macOS.
Pero recientemente Macports decidió actualizar Paramiko de la versión 1.16.0 a 2.0.1 y cuando ahora ejecutamos Fabric, ya no funciona:

➜ 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

Lo solucioné al degradar Paramiko a la versión 1.16.0 usando Macports, lo cual fue un poco complicado de hacer manualmente, pero finalmente lo volví a funcionar.

Creo que esto es un error de Macports, deberían haber esperado para actualizar Paramiko en su árbol hasta que Fabric fuera compatible.

Pero de todos modos, sería genial si se pudiera lanzar una nueva versión de Fabric con soporte para Paramiko> 2.0 para que podamos hacer que todo vuelva a funcionar usando Macports con las últimas versiones de todos los puertos.

Grump, eso es molesto, gracias por la noticia, @hostep. (No estoy tratando de ser sarcástico, pero también me sorprende que MacPorts todavía esté en uso, todos los que conozco se cambiaron a Homebrew hace años. ¡Un buen recordatorio de que "top of mind"! = "El único juego en la ciudad", supongo :))

Anoche saqué un pequeño 1.12 por capricho (otro buen recordatorio para mí mismo: deje de usar números de versión literales cuando discuta la hoja de ruta, solo diga "una próxima versión de función", etc.) y no hice este cambio, pero aún así quiero hazlo pronto, así que probablemente la próxima versión menor.

FWIW, nosotros (FreeBSD) experimentamos el mismo problema y tuvimos que crear un puerto y un paquete paramiko1 para que py-fabric dependiera. Ver también:

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

TLDR: <= y == las dependencias son súper dolorosas / molestas y crean más problemas de los que pretenden resolver.

Hay mucho menos dolor para los usuarios intermedios y los empaquetadores / portadores cuando los upstream solo prueban proactivamente las últimas versiones de sus dependencias (en desarrollo, antes de las versiones es el mejor momento para hacer esto) y no prescriben o restringen versiones de dependencia a menos que hay versiones que rompen explícitamente la compatibilidad.

Incluso en ese caso, la limitación es solo temporal, y solo si se realiza una publicación mientras está rota, y solo mientras se notifica a los autores de las dependencias y hasta que se realicen las correcciones.

La ventaja de este método es que les enseña a los upstreams (y upstreams de los upstreams) que las decisiones que toman realmente afectan a sus usuarios en la práctica (no solo en teoría), y con este conocimiento, con suerte, minimiza la probabilidad de que vuelva a suceder en el futuro.

Para agregar un poco más de información sobre el problema de Macports, parece estar solucionado porque agregaron un parche durante la instalación que cambia el requisito para Paramiko de <2.0 a <3.0
Ahora ejecutamos Fabric v1.12.0 y Paramiko v2.0.2 en nuestras estaciones de trabajo macOS y no tenemos problemas con esto.

@hostep Gracias por resaltar eso

@hostep De hecho, hay ocasiones en las que he anulado las especificaciones de *_requires (desde <= / == a >= o '' ) en FreeBSD puertos, si el conjunto de pruebas ha pasado con una versión posterior de la dependencia. Sin embargo, esto se basa en lo asombroso de las pruebas, por lo que puede ser arriesgado, y aunque somos una cadena descendente de Fabric, tampoco nos gusta romper nuestros entornos de usuario (aguas abajo) :)

Más actualizaciones de números ... resumen de los últimos 6 meses:

screen shot 2016-12-05 at 6 27 27 pm

y últimas 2 semanas:

screen shot 2016-12-05 at 6 35 09 pm

Paramiko 2.0.x ahora fácilmente la mitad de todas las descargas. Y me pregunto cuánto del otro 50% se debe a que este boleto no se fusionó :) ¡Lo sabremos pronto!

Creo que lo ejecutaré y lo sacaré como Fab 1.13.0.

Revisé lo que extras_require parece solo necesaria si quisiera limitar el cambio a PyPy; en este punto solo estoy haciendo el bit "permitir Paramiko <3" al por mayor ...

Hay PyPI

¡Por supuesto que olvidé el boleto de hermanos, # 1462! 1.13.1 en camino ... EDIT: y, fusionado / liberado.

¡Hurra!

El 9 de diciembre de 2016 a las 20:14, "Jeff Forcier" [email protected] escribió:

Gah, por supuesto que olvidé el boleto del hermano, # 1462
https://github.com/fabric/fabric/pull/1462 ! 1.13.1 en camino ...

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/fabric/fabric/issues/1461#issuecomment-266111875 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAUIXlbJBlS0po_zKgQsUp7-y7I7WgbTks5rGbajgaJpZM4ITeNm
.

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

Temas relacionados

TimotheeJeannin picture TimotheeJeannin  ·  3Comentarios

Grazfather picture Grazfather  ·  4Comentarios

shadyabhi picture shadyabhi  ·  5Comentarios

acdha picture acdha  ·  4Comentarios

supriyopaul picture supriyopaul  ·  4Comentarios