Celery: Sortir la version 4.3 de Céleri

@auvipy @thedrow @georgepsarakis pouvons-nous publier rapidement 4.2.2 juste pour la limitation redis ? car il est actuellement en conflit avec le dernier redis qui a des modifications incompatibles

Je ne sais pas si j'aurai le temps. Je vais essayer de le faire.

Je peux libérer cette fois mais j'ai besoin d'instructions claires

Ce serait en effet gr8 d'obtenir une 4.2.2 incluant le correctif de la dépendance de Redis, car j'ai déjà passé trop de temps à trouver la source du problème, et ce serait bien pour toute personne qui se lance dedans !

Cette nouvelle version prendra-t-elle en charge python 3.7 ?

Oui

Cette nouvelle version prendra-t-elle en charge redis 3.0.1 ?

Oui

@auvipy , @thedrow , Quelque chose que je puisse aider pour cette version ?

Le problème #5212 est essentiel à la publication.
Nous devons encore tester Celery avec Python 3.7.

@thedrow On dirait que #5212 est corrigé si nous faisons une version Kombu, non?
SI c'est correct, nous devons ajouter des tests 3.7 à notre CI. Je peux travailler là-dessus.

La version py-amqp et kombu est la pré-requis, après cela, je peux peaufiner mon pr pour le support 3.7 pour le fusionner

@auvipy Vous voulez dire ce PR : https://github.com/celery/celery/pull/4859 ?

J'ai publié Kombu 4.2.2 avec ce correctif uniquement.
La construction devrait passer maintenant.

Une idée d'ETA pour la sortie de cette version ?

Il y a encore du travail à faire. Nous devons également corriger la version pour Kombu.
Je vais passer en revue les problèmes restants.

@thedrow Un problème que je peux prendre en charge ?
Ou allez-vous énumérer les problèmes restants ici ?

@xirdneh, vous pouvez vérifier le jalon https://github.com/celery/celery/milestone/20 .

Je pense que nous pouvons supprimer les non-bloquants de cette étape. et se pencher sur les problèmes restants. publier py-amqp et les packages associés pour vérifier leur fonctionnement sur celery 4.3 rc1

À l'heure actuelle, la construction de master échoue sur Python 3.7.
Voir https://travis-ci.org/celery/celery/jobs/473236382.

@thedrow Je pense que cela est dû au fait que Python 3.7 convertit les exceptions StopIteration levées dans les générateurs, en exceptions RuntimeError , voir ici .

Ma suggestion serait d'ajouter une branche de gestion des exceptions, détectant le type spécifique 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

Certes, ce qui précède pourrait être considéré comme faible, mais je pense que c'est la seule méthode d'identification de la conversion d'exception, dans ce cas particulier.

Ce correctif est incorrect.
Voir https://github.com/celery/celery/blob/master/t/unit/worker/test_loops.py#L386
Selon le PEP 479, les générateurs devraient plus récolter StopIterator .

Cela devrait être corrigé dans #5263.

Il semble que nous ayons découvert un problème plus grave qui est à mon avis un bloqueur.
Voir https://travis-ci.org/celery/celery/jobs/473900629#L3204

Espérons que https://github.com/celery/kombu/pull/972 résoudra ce problème.

La construction de kombu est cassée, donc toute la suite de tests ne s'exécute pas.
Voir https://travis-ci.org/celery/kombu/jobs/472712374#L1215.

Je ne peux pas reproduire l'échec du test pour kombu localement :(

@thedrow J'ai corrigé les tests de kombu défaillants - voir PR https://github.com/celery/kombu/pull/978. Les tests utilisaient la bibliothèque pyamqp de master. Les tests ont cassé PR https://github.com/celery/py-amqp/pull/221.

Peut-être qu'un fruit bas serait de réparer le couple 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 est maintenant disponible.
Vient ensuite Kombu.

@thedrow Que manque-t-il à la version 4.3 ? Le Kombu PR semble déjà fusionné - attendons-nous une nouvelle version de Kombu ? Attendons-nous des correctifs pour tout sur https://github.com/celery/celery/milestone/20 ?

J'essaie de voir où je peux aider.

Je dois trier les problèmes critiques pour Kombu 4.3.
Tout dans https://github.com/celery/celery/issues?q=is%3Aopen+label%3A%22Status%3A+Needs+Test+Coverage+%E2%9C%98%22+milestone%3Av4.3 ou https://github.com/celery/kombu/pull/911 vous aidera.
Je pense que nous sommes à peu près prêts pour une sortie de Kombu mais je dois vérifier.
En attendant, je travaille sur les notes de version.

Pouvons-nous également résoudre le différend au #5259 ?

Comme je ne pouvais pas éditer celery/kombu#911, j'ai ouvert un nouveau PR : https://github.com/celery/kombu/pull/991

Et idem pour #5206 . J'ai ouvert #5289

À propos de ce truc StopIteration : dans Kombu, il a été modifié pour ne pas "convertir" le ValueError en StopIteration https://github.com/celery/kombu/pull/972/ des dossiers

Cependant, dans le céleri worker.loops.asynloop une erreur StopIteration est détectée et une nouvelle boucle est créée dans ce cas. Le changement de kombu sans changement de céleri ne causera-t-il pas quelques problèmes ? Parce que maintenant, au lieu de créer une nouvelle boucle, la boucle existante (mais cassée ?) continue d'être utilisée ?

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

@larsrinn, veuillez ouvrir un problème à ce sujet afin que nous

Lors de la rédaction du ticket, j'ai compris qu'aucune action n'était requise car le retour d'un générateur augmente StopIteration . Le comportement externe du kombu sur lequel le céleri s'appuie ici ne doit pas être modifié. Voir par exemple :

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

Le test d'échec sur CI pour Python 3.7 réussit également s'il est exécuté sur la branche principale de kombu. Du moins pour moi localement. Ainsi, lorsque la nouvelle version de kombu sera publiée, le test ayant échoué dans ce travail devrait réussir : https://travis-ci.org/celery/celery/jobs/482062153

Cela inclura-t-il un correctif pour le problème asynchrone ?
j'espère que cela sortira le plus tôt possible.

Oui, je l'attends aussi.

Mais je dois dire que j'ai un peu peur pour l'avenir du céleri. Python 3.7 est sorti depuis 7 mois déjà et n'est toujours pas pris en charge. Je sais que ce projet est géré par des bénévoles qui ont probablement une tonne d'autres choses à faire. Mais j'ai contribué à quelques relations publiques au cours des dernières semaines, principalement en ajoutant une couverture de test et en faisant passer le CI. Il semble qu'aucun d'entre eux n'ait été examiné, et encore moins fusionné, même s'ils sont tous si mineurs, les critiques devraient être réalisables en quelques minutes, voire quelques secondes. C'est une expérience de contribution assez décevante.

Ce serait une grande amélioration pour le projet de faire des versions beaucoup plus petites. 4.3 est une grosse version qui a encore besoin de travail, et en attendant, de nombreux utilisateurs ont des problèmes critiques comme la grave fuite de mémoire , qui pourrait être corrigé rapidement dans une version 4.2.X. Même contribuer à un correctif particulier n'est pas très utile car il ne sera pas publié avant des mois.

@larsrinn Je

Ce serait une grande amélioration pour le projet de faire des versions beaucoup plus petites. 4.3 est une grosse version qui a encore besoin de travail, et en attendant, de nombreux utilisateurs ont des problèmes critiques comme la fuite de mémoire grave, qui pourrait être corrigée rapidement dans une version 4.2.X. Même contribuer à un correctif particulier n'est pas très utile car il ne sera pas publié avant des mois.

Oui, je peux certainement soutenir cela. Considérant que le céleri est un projet assez mature avec un ensemble de fonctionnalités massif, je suppose que pour la plupart des utilisateurs, il est beaucoup plus important que les problèmes critiques soient résolus rapidement et que la compatibilité avec les dernières versions soit assurée que d'ajouter de nouvelles fonctionnalités/déprécier d'anciens éléments.

Je suis tout à fait d'accord avec les affirmations ci-dessus. La prise en charge de Python 3.7 est la chose la plus importante pour moi en ce moment.

Existe-t-il une option pour ajouter des mainteneurs supplémentaires ?

La plupart des entreprises dans lesquelles j'ai travaillé au cours des 9 dernières années ont utilisé le céleri d'une manière ou d'une autre. Dans le dernier, nous avions même notre propre fork afin d'appliquer les correctifs dont nous avions besoin, étant donné que nos problèmes n'étaient pas résolus dans la branche grand public.

À mon avis, ce projet doit démarrer un programme de parrainage, tout comme Django et DRF l'ont fait. Faites payer aux entreprises tous les bénéfices qu'elles réalisent grâce à ce projet incroyable et donnez cet argent aux développeurs pour qu'ils y travaillent à temps plein.

Le céleri est légèrement cassé par rapport au pytest actuel (un autre module populaire); #5271 décrit le problème et #5097 le résout. Peut-être que si la version 4.3 devient trop intimidante, une modification mineure de la version 4.2.2 pourrait entraîner plusieurs correctifs plus petits (#5271 et autres corrections de bogues) ? Je me rends compte que c'est probablement plus facile à dire qu'à faire, mais cela pourrait permettre à un groupe d'entre nous de rejoindre le cycle de publication au lieu de maintenir nos propres forks en attendant la 4.3. Merci pour cet excellent module.

alors quelles entreprises vont sponsoriser notre travail ? Est-ce que quelqu'un est intéressé ? Je serai très intéressé d'obtenir que certaines entreprises soutiennent mon temps pour travailler avec le céleri à temps partiel/à temps plein !

Je suis sûr que s'il y avait une configuration appropriée pour les dons réguliers, il serait plus facile pour les entreprises de simplement souscrire à un support mensuel et de l'oublier. Cela pourrait être la source d'un revenu plus stable qu'un simple bouton de don unique paypal. Je pourrais facilement convaincre mon entreprise de le faire par exemple, que de leur demander de donner beaucoup en une seule fois, ou de leur rappeler de faire un don manuel régulier.

J'ajouterais aussi, pour notre projet, le céleri est le seul bloqueur qui nous empêche de passer à python 3.7

un lien connexe : https://tidelift.com/

Je pense que le sponsoring est tout à fait possible, mais il faut planter l'idée dans la tête des gens. Par exemple, en dehors de ce fil, personne ne pense même que ce projet peut avoir besoin d'aide, ils téléchargent et installent simplement le céleri et pensent qu'il "existe". Je pense que si vous aviez lancé une collecte de fonds, beaucoup d'entreprises feraient un don.
J'ai vu le lien de donation dans le README et j'ai contribué un peu à partir d'un compte personnel, mais c'est encore trop obscur pour que les entreprises le remarquent. Il devrait être juste devant eux (au moins dans tous les réseaux sociaux) et il devrait y avoir un appel à l'action approprié. Par exemple, si vous êtes un développeur et que vous savez que votre entreprise dépend du céleri, demandez à votre responsable de faire un don.
Je peux dire que chaque fois que je vois des collectes de fonds organisées à partir des projets open source que j'aime, j'essaie toujours de faire un don ou au moins de diffuser leur campagne sur les réseaux sociaux. Je suis sûr que beaucoup de gens font de même.

J'ai organisé une collecte de fonds et cela s'est transformé en un échec massif !! nous avons l'option opencollective et tide lift ouverte dans le readme. les personnes intéressées peuvent y faire un don/sponsoriser ou me contacter directement dans mon e-mail.

@auvipy J'ai vu que la plupart des problèmes du jalon 4.3 ont été déplacés ou fermés maintenant.
Prévoyons-nous de faire une version 4.3 bientôt ?

Oui!!! car c'est trop tard !!

Je suis dessus. Attendez-vous à un RC très bientôt.

J'ai organisé une collecte de fonds et cela s'est transformé en un échec massif !! nous avons l'option opencollective et tide lift ouverte dans le readme. les personnes intéressées peuvent y faire un don/sponsoriser ou me contacter directement dans mon e-mail.

Auteurs de céleri. Je suis devenu un backer de https://opencollective.com/celery. Merci pour votre formidable outil. Vos outils m'aident beaucoup :)

Quelqu'un s'oppose au nom de code 4.3 comme Rhubarbe ?
C'est l'un de mes morceaux préférés de Selected Ambient Works II.

Si vous avez d'autres suggestions, veuillez les noter ici.

Je l'aime bien :)

Kombu 4.3 est maintenant disponible !

Quelqu'un peut-il jeter un œil à notre version de Windows ?
Certains tests échouent.
De plus, il nous manque quelques versions de Python, nous devrions les ajouter (bien que ce ne soit pas un bloqueur).

@thedrow Où

Quelqu'un peut-il jeter un œil à notre version de Windows ?
Certains tests échouent.
De plus, il nous manque quelques versions de Python, nous devrions les ajouter (bien que ce ne soit pas un bloqueur).

PR ici https://github.com/celery/celery/pull/5329

Donc 4.3 est bon pour aller maintenant?

Salut! Vous avez fermé ce problème, mais la version sur pypi est toujours 4.2.1. Y a-t-il quelque part où nous pouvons suivre la sortie sur pypi ? Merci.

Salut les gens,

@seirl Je pense que ce problème a été fermé accidentellement car la description de #5329 contient du texte Fixes #5180 .

@auvipy Pourriez-vous s'il vous plaît rouvrir ce problème jusqu'à ce que 4.3 ne soit pas réellement publié ?
Merci!

Mon mauvais, je pensais que la fermeture automatique serait juste une option pour la poulie

cela a été fermé automatiquement par GitHub !!!

@xirdneh ouais .

J'ai presque fini avec le Changelog. Je dois encore élaborer sur certains des éléments et je dois terminer d'ajouter les éléments restants auxquels je n'ai pas pu accéder.

La section Quoi de neuf est encore largement incomplète.

N'hésitez pas à aider de toutes les manières possibles.

Nous avons un bloqueur potentiel pour GA : https://github.com/celery/kombu/issues/1006
Les CR se dérouleront comme prévu.
Quelqu'un ayant accès à un FreeBSD peut-il installer cela ?

Bonjour à tous. Une heure d'arrivée prévue ?

Je viens de terminer les notes de version pour la première RC.
Il va sortir aujourd'hui.

Avez-vous un ETA pour une version stable ?

Une fois que cela aura été essayé en production pendant quelques semaines, nous déclarerons GA.
Dans un avenir proche, nous améliorerons notre processus de publication et le documenterons afin que tout soit plus clair.

RC1 est libéré. :tada:
Veuillez l'essayer dans vos environnements de développement.

En attendant, si quelqu'un peut regarder de plus près https://github.com/celery/kombu/issues/1006 , https://github.com/celery/kombu/issues/1007 et https://github. com/celery/kombu/issues/1004 qui sont toutes des régressions de Kombu 4.3, qui nous aideront à atteindre l'AG.

J'ai fait un correctif potentiel pour https://github.com/celery/kombu/issues/1007 dans https://github.com/celery/kombu/pull/1009

Étant donné que https://github.com/celery/kombu/issues/1004 semblait être dans la même zone, j'ai également tenté un correctif pour cela : https://github.com/celery/kombu/pull/1010

Les deux sont désormais fusionnés.

@lithammer Merci !

Comme c'était tellement amusant, je viens avec non pas une, mais deux propositions de solutions pour le dernier problème (https://github.com/celery/kombu/issues/1006) :

• Proposition 1 : https://github.com/celery/kombu/pull/1011 (favori personnel)
• Proposition 2 : https://github.com/celery/kombu/pull/1012

J'ai pris une courte pause dans les notes de version pour écrire https://github.com/celery/py-amqp/pull/258.
Je vais continuer avec notre nouveau document.

J'ai sorti Kombu 4.4 et Celery 4.3.0RC2.
À moins qu'il n'y ait une objection ou un correctif critique, ce sera le dernier RC.

Je viens également de publier py-amqp 2.4.3.
Il corrige deux graves bugs de désérialisation. Je n'ai rien entendu à leur sujet en production.
Probablement parce qu'il n'y a pas de messages dans le protocole AMQP avec deux bitmaps conséquents.
Les correctifs sont là pour être complets car je suppose qu'ils pourraient faire planter Celery.

Merci pour l'excellent travail @thedrow.

Bloqueur potentiel pour GA : https://github.com/celery/celery/issues/5371

@thedrow Je pourrais avoir un peu de temps cette semaine pour vérifier cela. Je mettrai à jour le problème si je le peux.

@xirdneh Veuillez mettre à jour si vous ne le faites pas et je m'en

@lithammer Si vous avez envie de contribuer davantage, je vous accorderai même des droits de commit :)

Bloqueur définitif pour GA : #5377

J'ai terminé notre document sur

Veuillez le consulter et me faire savoir si j'ai raté quelque chose.

@thedrow semble assez complet et informatif! Une remarque cependant, je ne suis pas sûr qu'il soit automatiquement inclus d'une manière ou d'une autre, mais il me semble que la liste des contributeurs n'a pas encore été ajoutée ?

Je n'ai pas encore généré la liste des contributions.
Je vais le faire juste avant l'AG.

Voici une liste de nos bloqueurs de version actuels :

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

Bloqueurs potentiels :

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

@thedrow Je pense que https://github.com/celery/celery/issues/5383 est également valide.

Je viens de sortir Celery 4.3.0rc3.
Cela inclut de nouvelles fonctionnalités et des corrections de bugs et certains bloqueurs résolus.

Savez-vous peut-être quand la version complète sera disponible ?

Quand nous aurons fini de résoudre tous les bloqueurs.

Il ne reste qu'un seul bloqueur et quelques tâches de documentation finales.

@thedrow ressemble à celery/kombu#1014 a été fermé par un PR basé sur le retour. Cependant, il n'apparaît pas comme complet sur la liste de contrôle. Est-il incomplet, car le mot clé unique doit encore être pris en charge ?

Oui. Je ferai cela et les tâches de documentation finales demain.

Publié! :tada:

Merci à tous pour vos efforts, votre temps et vos compétences.

La prochaine version, Celery 5 est quelque chose dont il faut être excité.

Je veux commencer à supprimer python2 du maître

Puis-je savoir quand le Celery 5 sortira-t-il ? Je suis vraiment excité d'utiliser ça.

peut-être quelques fois avant Noël :)

@auvipy Pouvez-vous publier un article de blog sur la 4.3 ?

oui bien sûr, j'ai commencé kast ng=ight mais je suis devenu occupé. se terminera d'ici aujourd'hui.