Celery: Lanzamiento de la versión 4.3 de Apio

@auvipy @thedrow @georgepsarakis ¿podemos hacer una versión rápida de 4.2.2 solo por la limitación de redis? ya que actualmente choca con el último redis que tiene cambios incompatibles

No estoy seguro de si tendré tiempo. Intentaré hacerlo.

Puedo liberar esta vez, pero necesito instrucciones claras.

De hecho, sería genial obtener una versión 4.2.2 que incluye la solución de dependencia de redis, porque ya pasé demasiado tiempo para encontrar la fuente del problema, ¡y sería bueno para cualquier persona que se lanzara a ello!

¿Esta nueva versión será compatible con Python 3.7?

sí

¿Esta nueva versión será compatible con redis 3.0.1?

sí

@auvipy , @thedrow , ¿puedo ayudar en algo para esta versión?

El número 5212 es fundamental para el lanzamiento.
Todavía necesitamos probar Celery con Python 3.7.

@thedrow Parece que el # 5212 está arreglado si hacemos un lanzamiento de Kombu, ¿verdad?
SI eso es correcto, entonces necesitamos agregar 3.7 pruebas a nuestro CI. Puedo trabajar en eso.

El lanzamiento de py-amqp y kombu es el requisito previo, después de eso, puedo pulir mi pr para obtener soporte 3.7 para fusionarlo

@auvipy ¿ Te refieres a este PR: https://github.com/celery/celery/pull/4859 ?

Lancé Kombu 4.2.2 solo con esa solución.
La construcción debería pasar ahora.

¿Alguna idea de una ETA para que se lance esta versión?

Aún queda trabajo por hacer. Necesitamos arreglar la compilación de Kombu también.
Revisaré los problemas restantes.

@thedrow ¿ Algún problema que pueda asumir?
¿O va a enumerar los problemas restantes aquí?

@xirdneh puede consultar el hito https://github.com/celery/celery/milestone/20 .

Creo que podemos eliminar a los no bloqueadores de este hito. e inclinarse hacia los temas restantes. lanzando py-amqp y paquetes relacionados para comprobar cómo funcionan en apio 4.3 rc1

En este momento, la compilación del maestro está fallando en Python 3.7.
Consulte https://travis-ci.org/celery/celery/jobs/473236382.

@thedrow Creo que esto se debe a que Python 3.7 convierte las excepciones StopIteration generadas en los generadores, en excepciones RuntimeError , consulte aquí .

Mi sugerencia sería agregar una rama de manejo de excepciones, detectando el tipo específico de RuntimeError :
https://github.com/celery/kombu/blob/e4dc1688a2bfe422813ffc79d9db50c06f38fbaf/kombu/asynchronous/hub.py#L348 -L359

except RuntimeError as e:
  if e.args != ('generator raised StopIteration',):
      raise e

Es cierto que lo anterior podría considerarse de alguna manera débil, pero creo que es el único método para identificar la conversión de excepción, en este caso particular.

Esa solución es incorrecta.
Ver https://github.com/celery/celery/blob/master/t/unit/worker/test_loops.py#L386
Según PEP 479, los generadores deberían recaudar más StopIterator .

Esto debería arreglarse en # 5263.

Parece que hemos descubierto un problema más grave que, en mi opinión, es un bloqueador.
Ver https://travis-ci.org/celery/celery/jobs/473900629#L3204

Con suerte, https://github.com/celery/kombu/pull/972 resolverá este problema.

La compilación de kombu está rota, por lo que no se ejecuta todo el conjunto de pruebas.
Ver https://travis-ci.org/celery/kombu/jobs/472712374#L1215.

No puedo reproducir la falla de la prueba para kombu localmente :(

@thedrow He arreglado las pruebas de kombu https://github.com/celery/kombu/pull/978. Las pruebas estaban usando la biblioteca pyamqp de master. Las pruebas rompieron PR https://github.com/celery/py-amqp/pull/221.

Tal vez una fruta madura sería arreglar a la pareja DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

Py-amqp 2.4.0 ya está disponible.
El siguiente a su vez es Kombu.

@thedrow ¿Qué falta en la versión 4.3? Kombu PR parece haberse fusionado ya, ¿estamos esperando un nuevo lanzamiento de Kombu? ¿Estamos esperando arreglos para todo en https://github.com/celery/celery/milestone/20?

Tratando de ver dónde puedo ayudar.

Necesito clasificar los problemas que son críticos para Kombu 4.3.
Cualquier cosa en https://github.com/celery/celery/issues?q=is%3Aopen+label%3A%22Status%3A+Needs+Test+Coverage+%E2%9C%98%22+milestone%3Av4.3 o https://github.com/celery/kombu/pull/911 ayudará.
Creo que estamos bastante listos para un lanzamiento de Kombu, pero necesito verificarlo.
Mientras tanto, estoy trabajando en las notas de la versión.

¿Podemos también resolver la disputa en el n. ° 5259?

Como no pude editar apio / kombu # 911, abrí un nuevo PR: https://github.com/celery/kombu/pull/991

Y lo mismo para el # 5206. Abrí # 5289

Acerca de eso StopIteration cosas: En Kombu se cambió para no "convertir" el ValueError en StopIteration https://github.com/celery/kombu/pull/972/ archivos

Sin embargo, en apio worker.loops.asynloop se detecta un error StopIteration y se crea un nuevo bucle en ese caso. ¿El cambio de kombu sin un cambio de apio no causará algunos problemas? ¿Porque ahora, en lugar de crear un nuevo bucle, se sigue utilizando el bucle existente (¿pero roto?).

https://github.com/celery/celery/blob/c1d0bfea9ad98477cbc1def99157fe5109555500/celery/worker/loops.py#L92

@larsrinn , abre un problema al respecto para que no nos olvidemos de investigarlo.

Mientras escribía el boleto, descubrí que no se requiere ninguna acción ya que regresar de un generador genera StopIteration . El comportamiento externo del kombu en el que se basa el apio aquí no debe cambiarse. Ver por ejemplo:

def len_generator(max_):
    a = 0

    while True:
        yield a
        a += 1
        if a == max_:
            return


g = len_generator(2)
print(next(g))  # 0
print(next(g))  # 1
print(next(g))  # raises StopIteration

La prueba fallida en CI para Python 3.7 también pasa si se ejecuta contra la rama maestra de kombu. Al menos para mí a nivel local. Entonces, cuando se lance la nueva versión de kombu, la prueba fallida en este trabajo debería pasar: https://travis-ci.org/celery/celery/jobs/482062153

¿Esto incluirá una solución para el problema asincrónico?
Espero que esto se publique lo antes posible.

Sí, yo también lo estoy esperando.

Pero debo decir que tengo un poco de miedo por el futuro del apio. Python 3.7 ya está disponible durante 7 meses y aún no es compatible. Sé que este proyecto está dirigido por voluntarios que probablemente tengan muchas otras cosas que hacer. Pero contribuí con un par de relaciones públicas en las últimas semanas, principalmente agregando cobertura de prueba y logrando que el IC pasara. Parece que ninguno de ellos ha sido examinado, y mucho menos fusionado, aunque todos son tan menores, las revisiones deberían ser factibles en unos minutos, si no en segundos. Esta es una experiencia de contribución bastante decepcionante.

Sería una gran mejora para el proyecto hacer lanzamientos mucho más pequeños. 4.3 es una gran versión que aún necesita ser mejorada y, mientras tanto, muchos usuarios tienen problemas críticos como la pérdida grave de memoria , que podría solucionarse rápidamente en una versión 4.2.X. Incluso aportar una solución en particular no es muy útil porque no se lanzará durante meses.

@larsrinn Revisaré sus relaciones públicas si tengo tiempo.

Sería una gran mejora para el proyecto hacer lanzamientos mucho más pequeños. 4.3 es una gran versión que aún necesita ser mejorada y, mientras tanto, muchos usuarios tienen problemas críticos como la pérdida grave de memoria, que podría solucionarse rápidamente en una versión 4.2.X. Incluso aportar una solución en particular no es muy útil porque no se lanzará durante meses.

Sí, definitivamente puedo respaldar esto. Teniendo en cuenta que el apio es un proyecto bastante maduro con un conjunto de características masivo, supongo que para la mayoría de los usuarios es mucho más importante que los problemas críticos se solucionen rápidamente y se garantice la compatibilidad con las últimas versiones que agregar nuevas características / desaprobar las cosas viejas.

Definitivamente estoy de acuerdo con las declaraciones anteriores. La compatibilidad con Python 3.7 es lo más importante para mí en este momento.

¿Existe una opción para agregar mantenedores adicionales?

La mayoría de las empresas en las que he trabajado durante los últimos 9 años usaban Apio de una forma u otra. En el último, incluso teníamos nuestra propia bifurcación para aplicar las correcciones que necesitábamos, dado que nuestros problemas no se solucionaron en la rama principal.

En mi opinión, este proyecto necesita iniciar un programa de patrocinio, como lo han hecho Django y DRF. Hacer que las empresas paguen por todas las ganancias que obtienen gracias a este increíble proyecto y dar ese dinero a los desarrolladores para que trabajen a tiempo completo en esto.

El apio está ligeramente roto contra el pytest actual (otro módulo popular); # 5271 describe el problema y # 5097 lo soluciona. ¿Quizás si la versión 4.3 se está volviendo demasiado abrumadora, un salto de versión menor a 4.2.2 podría acumular varias correcciones más pequeñas (# 5271 y otras correcciones de errores)? Me doy cuenta de que probablemente sea más fácil decirlo que hacerlo, pero podría permitirnos unirnos al ciclo de lanzamiento en lugar de mantener nuestras propias bifurcaciones mientras esperamos la versión 4.3. Gracias por este excelente módulo.

entonces, ¿qué empresas van a patrocinar nuestro trabajo? ¿Alguien está interesado? ¡Estaré muy interesado en que algunas empresas respalden mi tiempo para trabajar con apio a tiempo parcial / tiempo completo!

Estoy seguro de que si hubiera una configuración adecuada para las donaciones regulares, sería más fácil para las empresas suscribirse para recibir un soporte mensual y olvidarse de él. Esta podría ser la fuente de ingresos más estables que un simple botón de donación de una sola vez de PayPal. Podría convencer fácilmente a mi empresa de que lo haga, por ejemplo, que pedirles que den mucho de una vez o que recuerden que deben hacer una donación manual regular.

También agregaría, para nuestro proyecto, el apio es el único bloqueador que nos impide actualizar a Python 3.7

un enlace relacionado: https://tidelift.com/

Creo que el patrocinio es muy posible, pero es necesario plantar la idea en la cabeza de la gente. Por ejemplo, fuera de este hilo, nadie piensa que este proyecto pueda necesitar soporte, simplemente descargan e instalan apio y piensan que simplemente "existe". Creo que si ustedes hubieran comenzado una recaudación de fondos, muchas empresas donarían.
Vi el enlace de donación en el archivo README y contribuí un poco desde una cuenta personal, pero todavía es demasiado oscuro para que las empresas lo noten. Debe estar justo frente a ellos (al menos en todas las redes sociales) y debe tener un llamado a la acción adecuado. Por ejemplo, si es un desarrollador y sabe que su empresa depende del apio, pídale a su gerente que done.
Puedo decir que cada vez que veo eventos de recaudación de fondos organizados de los proyectos de código abierto que me gustan, siempre trato de donar o al menos difundir su campaña en las redes sociales. Estoy seguro de que mucha gente hace lo mismo.

¡¡Hice una recaudación de fondos y se convirtió en un gran fracaso !! tenemos abierta la opción de elevación de marea y colectivo abierto en el archivo Léame. las personas interesadas pueden donar / patrocinar allí o enviarme un ping directamente en mi correo electrónico.

@auvipy Vi que la mayoría de los problemas en el hito 4.3 se movieron o cerraron ahora.
¿Estamos planeando hacer una versión 4.3 pronto?

¡¡¡sí!!! ya que es un largo retraso !!

Estoy en ello. Espere un RC muy pronto.

¡¡Hice una recaudación de fondos y se convirtió en un gran fracaso !! tenemos abierta la opción de elevación de marea y colectivo abierto en el archivo Léame. las personas interesadas pueden donar / patrocinar allí o enviarme un ping directamente en mi correo electrónico.

Autores de apio. Me he convertido en patrocinador de https://opencollective.com/celery. Gracias por tu increíble herramienta. Tus herramientas me están ayudando mucho :)

¿Alguien se opone al nombre en clave 4.3 como ruibarbo ?
Es una de mis pistas favoritas de Selected Ambient Works II.

Si tiene otras sugerencias, anótelas aquí.

Me gusta :)

¡Kombu 4.3 ya está disponible!

¿Alguien puede echar un vistazo a nuestra compilación de Windows?
Algunas de las pruebas fallan.
Además, nos faltan algunas versiones de Python, deberíamos agregarlas (aunque eso no es un bloqueador).

@thedrow ¿Dónde se está ejecutando la compilación de Windows? Appveyor?

¿Alguien puede echar un vistazo a nuestra compilación de Windows?
Algunas de las pruebas fallan.
Además, nos faltan algunas versiones de Python, deberíamos agregarlas (aunque eso no es un bloqueador).

PR aquí https://github.com/celery/celery/pull/5329

Entonces, ¿4.3 está listo ahora?

¡Hola! Cerró este problema, pero la versión en pypi sigue siendo 4.2.1. ¿Hay algún lugar donde podamos rastrear el lanzamiento en pypi? Gracias.

Hola amigos,

@seirl Creo que este problema se cerró accidentalmente debido a que la descripción de # 5329 contiene Fixes #5180 texto.

@auvipy ¿Podrías volver a abrir este problema hasta que no se publique 4.3 ?
¡Gracias!

Mi mal, pensé que el cierre automático sería solo una opción para pullee

esto fue cerrado automáticamente por GitHub !!!

@xirdneh sí .

Casi termino con el Changelog. Todavía tengo que desarrollar algunos de los elementos y necesito completar la adición de los elementos restantes a los que no he llegado.

La sección de novedades todavía está en gran parte incompleta.

Siéntase libre de ayudar de cualquier forma posible.

Tenemos un bloqueador potencial para GA: https://github.com/celery/kombu/issues/1006
Los RC procederán según lo planeado.
¿Alguien con acceso a una instalación de FreeBSD puede depurar esto?

Hola, todos. ¿Alguna ETA?

Acabo de terminar las notas de la versión del primer RC.
Se lanzará hoy.

¿Tiene alguna ETA para la liberación estable?

Una vez que esto se haya probado en producción durante un par de semanas, declararemos GA.
En un futuro próximo, mejoraremos nuestro proceso de lanzamiento y lo documentaremos para que todo sea más claro.

Se lanza RC1. : tada:
Pruébelo en sus entornos de ensayo.

Mientras tanto, si alguien puede echar un vistazo más de cerca a https://github.com/celery/kombu/issues/1006 , https://github.com/celery/kombu/issues/1007 y https: // github. com / celery / kombu / issues / 1004 que son todas regresiones de Kombu 4.3, que nos ayudarán a llegar a GA.

Hice una posible solución para https://github.com/celery/kombu/issues/1007 en https://github.com/celery/kombu/pull/1009

Dado que https://github.com/celery/kombu/issues/1004 parecía estar en la misma área, intenté una solución para eso también: https://github.com/celery/kombu/pull/1010

Ambos ahora están fusionados.

@lithammer ¡ Gracias!

Como esto fue tan divertido, vengo con no una, sino dos propuestas de solución para el último problema (https://github.com/celery/kombu/issues/1006):

• Propuesta 1: https://github.com/celery/kombu/pull/1011 (favorito personal)
• Propuesta 2: https://github.com/celery/kombu/pull/1012

Me tomé un breve descanso de las notas de la versión para escribir https://github.com/celery/py-amqp/pull/258.
Continuaré con nuestro documento de novedades.

Lancé Kombu 4.4 y Celery 4.3.0RC2.
A menos que haya alguna objeción o solución crítica, este será el último RC.

También acabo de lanzar py-amqp 2.4.3.
Corrige dos errores graves de deserialización. No he escuchado nada sobre ellos en producción.
Probablemente porque no hay mensajes en el protocolo AMQP con dos mapas de bits consecuentes.
Las correcciones están ahí para completarlo, ya que supongo que podrían bloquear Celery.

Gracias por el gran trabajo @thedrow.

Bloqueador potencial para GA: https://github.com/celery/celery/issues/5371

@thedrow Puede que tenga algo de tiempo esta semana para verificar esto. Actualizaré el problema si puedo.

@xirdneh Actualiza si no lo haces y yo me ocuparé de ello.

@lithammer Si tienes ganas de contribuir más, incluso te concederé derechos de compromiso :)

Bloqueador definitivo para GA: # 5377

He completado nuestro documento de novedades para esta versión.

Revíselo y avíseme si me perdí algo.

¡@thedrow parece bastante completo e informativo! Sin embargo, una nota, no estoy seguro de si se incluye automáticamente de alguna manera, pero me parece que la lista de colaboradores aún no se ha agregado.

Aún no he generado la lista de contribuciones.
Lo haré justo antes de GA.

Aquí hay una lista de nuestros bloqueadores de versiones actuales:

• [x] n.º 5377
• [x] # 5371
• [x] n.º 5328
• [x] n.º 4812
• [x] # 5383
• [x] n.º 5259
• [x] n.º 5007
• [x] https://github.com/celery/kombu/issues/1014

Bloqueadores potenciales:

• [] # 5358
• [] https://github.com/celery/kombu/issues/1019
• [] https://github.com/celery/kombu/issues/1018

@thedrow Creo que https://github.com/celery/celery/issues/5383 también es válido.

Acabo de lanzar Celery 4.3.0rc3.
Esto incluye nuevas funciones y correcciones de errores y algunos bloqueadores resueltos.

¿Quizás sepa cuándo estará disponible la versión completa?

Cuando terminemos de resolver todos los bloqueadores.

Solo queda un bloqueador y luego algunas tareas de documentación finales.

@thedrow parece que celery / kombu # 1014 ha sido cerrado por un PR basado en revertir. Sin embargo, no se muestra tan completo en la lista de verificación. ¿Está incompleto porque la palabra clave unique aún necesita ser compatible?

Si. Mañana haré eso y las tareas de documentación finales.

¡Liberado! : tada:

Gracias a todos por su esfuerzo, tiempo y habilidades.

La próxima versión, Celery 5, es algo por lo que estar emocionado.

Quiero comenzar a eliminar python2 del maestro

¿Puedo saber cuándo se lanzará el Apio 5? Estoy muy emocionado de usar eso.

tal vez algunas veces antes de Navidad :)

@auvipy ¿Puede publicar una publicación de blog sobre 4.3?

sí, por supuesto, comencé kast ng = ight pero me puse a trabajar. se completará hoy.