Celery: Versão de lançamento 4.3 do Celery

@auvipy @thedrow @georgepsarakis podemos lançar o 4.2.2 rapidamente apenas para a limitação do redis? pois atualmente colide com o redis mais recente, que tem alterações incompatíveis

Não tenho certeza se terei tempo. Vou tentar fazer isso.

Posso liberar desta vez, mas preciso de algumas instruções claras

Na verdade, seria gr8 obter um 4.2.2 incluindo a correção de dependência do redis, porque já gastei muito tempo para encontrar a origem do problema e seria bom para qualquer pessoa que o abordasse!

Esta nova versão oferecerá suporte ao python 3.7?

sim

Esta nova versão oferecerá suporte ao redis 3.0.1?

sim

@auvipy , @thedrow , em que posso ajudar neste lançamento?

O problema # 5212 é crítico para o lançamento.
Ainda precisamos testar o Celery com Python 3.7.

@thedrow Parece que o # 5212 será corrigido se
SE estiver correto, precisamos adicionar o teste 3.7 ao nosso CI. Eu posso trabalhar nisso.

A liberação de py-amqp e kombu é o pré-requisito, depois disso, posso polir meu pr para suporte 3.7 para mesclá-lo

@auvipy Você quer dizer este PR: https://github.com/celery/celery/pull/4859 ?

Lancei o Kombu 4.2.2 apenas com essa correção.
A construção deve passar agora.

Alguma ideia de um ETA para esta versão lançar?

Ainda há muito trabalho a fazer. Precisamos consertar a compilação do Kombu também.
Vou repassar as questões restantes.

@thedrow Qualquer problema que eu possa resolver?
Ou você vai listar os problemas restantes aqui?

@xirdneh você pode verificar o marco https://github.com/celery/celery/milestone/20 .

Acho que podemos remover os não bloqueadores deste marco. e diminuir as questões restantes. lançando py-amqp e pacotes relacionados para verificar como eles funcionam no celery 4.3 rc1

No momento, a compilação para mestre está falhando no Python 3.7.
Consulte https://travis-ci.org/celery/celery/jobs/473236382.

@thedrow Acho que isso se deve ao Python 3.7 convertendo StopIteration exceções levantadas em geradores em RuntimeError exceções, veja aqui .

Minha sugestão seria adicionar um branch de tratamento de exceção, detectando o 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

É certo que o exposto acima pode ser considerado de alguma forma fraco, mas acho que é o único método de identificar a conversão de exceção, neste caso específico.

Essa correção está incorreta.
Veja https://github.com/celery/celery/blob/master/t/unit/worker/test_loops.py#L386
De acordo com o PEP 479, os geradores devem levantar StopIterator mais.

Isso deve ser corrigido em # 5263.

Parece que descobrimos um problema mais sério que, em minha opinião, é um bloqueador.
Consulte https://travis-ci.org/celery/celery/jobs/473900629#L3204

Esperançosamente, https://github.com/celery/kombu/pull/972 resolverá esse problema.

A compilação do kombu está corrompida, portanto, todo o conjunto de testes não funciona.
Consulte https://travis-ci.org/celery/kombu/jobs/472712374#L1215.

Não consigo reproduzir a falha do teste para kombu localmente :(

@thedrow Corrigi testes de kombu com falha - consulte PR https://github.com/celery/kombu/pull/978. Os testes estavam usando a biblioteca pyamqp do mestre. Os testes quebraram PR https://github.com/celery/py-amqp/pull/221.

Talvez um fruto fácil fosse consertar o casal DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

O py-amqp 2.4.0 foi lançado.
O próximo, por sua vez, é Kombu.

@thedrow O que está faltando na versão 4.3? O Kombu PR parece já ter sido fundido - estamos esperando por um novo lançamento do Kombu? Estamos esperando por correções para tudo em https://github.com/celery/celery/milestone/20?

Tentando ver onde posso ajudar.

Eu preciso fazer a triagem dos problemas que são críticos para o Kombu 4.3.
Qualquer coisa em 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 ajudará.
Acho que estamos prontos para o lançamento do Kombu, mas preciso verificar.
Enquanto isso, estou trabalhando nas notas de lançamento.

Podemos também resolver a disputa em # 5259?

Como não consegui editar o celery / kombu # 911, abri um novo PR: https://github.com/celery/kombu/pull/991

E o mesmo para # 5206. Eu abri # 5289

Sobre as coisas de StopIteration : Em Kombu, foi alterado para não "converter" o ValueError em StopIteration https://github.com/celery/kombu/pull/972/ arquivos

No entanto, no aipo worker.loops.asynloop a StopIteration erro é detectado e um novo loop é criado nesse caso. A mudança no kombu sem uma mudança no aipo não causará alguns problemas? Porque agora, em vez de criar um novo loop, o loop existente (mas quebrado?) Continua a ser usado?

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

@larsrinn , abra um problema sobre isso para que não nos esqueçamos de examiná-lo.

Ao escrever o tíquete, descobri que nenhuma ação é necessária, pois o retorno de um gerador gera StopIteration . O comportamento externo do kombu, do qual o aipo se baseia aqui, não deve ser alterado. Veja por exemplo:

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

O teste de falha no CI para Python 3.7 também será aprovado se executado no branch mestre kombu. Pelo menos para mim localmente. Portanto, quando a nova versão do kombu for lançada, o teste de falha neste trabalho deve passar: https://travis-ci.org/celery/celery/jobs/482062153

Isso incluirá a correção do problema assíncrono?
Espero que isso seja lançado o mais rápido possível.

Sim, também estou esperando por isso.

Mas devo dizer que estou com um pouco de medo sobre o futuro do aipo. Python 3.7 já saiu há 7 meses e ainda não é compatível. Eu sei que este projeto é executado por voluntários que provavelmente têm uma tonelada de outras coisas para fazer. Mas eu contribuí com alguns PRs nas últimas semanas, principalmente adicionando cobertura de teste e fazendo com que o IC fosse aprovado. Parece que nenhum deles foi analisado, muito menos mesclado, embora sejam todos tão menores que as revisões devem estar disponíveis em alguns minutos, se não mesmo segundos. Esta é uma experiência de contribuição bastante decepcionante.

Seria uma grande melhoria para o projeto fazer lançamentos muito menores. 4.3 é uma grande versão que ainda precisa ser trabalhada e, enquanto isso, muitos usuários têm problemas críticos, como o grave vazamento de memória , que poderia ser corrigido rapidamente em uma versão 4.2.X. Até mesmo contribuir com uma correção específica não é muito útil porque ela não será lançada por meses.

@larsrinn Vou revisar seu PR se tiver tempo.

Seria uma grande melhoria para o projeto fazer lançamentos muito menores. 4.3 é uma grande versão que ainda precisa ser trabalhada e, enquanto isso, muitos usuários têm problemas críticos, como o grave vazamento de memória, que pode ser corrigido rapidamente em uma versão 4.2.X. Até mesmo contribuir com uma correção específica não é muito útil porque ela não será lançada por meses.

Sim, eu posso definitivamente apoiar isso. Considerando que o aipo é um projeto bastante maduro com um conjunto enorme de recursos, acho que para a maioria dos usuários é muito mais importante que os problemas críticos sejam corrigidos rapidamente e que a compatibilidade com as versões mais recentes seja garantida do que adicionar novos recursos / descontinuar coisas antigas.

Eu definitivamente concordo com as afirmações acima. O suporte ao Python 3.7 é a coisa mais importante para mim no momento.

Existe uma opção para adicionar mantenedores adicionais?

A maioria das empresas com as quais trabalhei nos últimos 9 anos usava o aipo de uma forma ou de outra. No último, até tínhamos nosso próprio fork para aplicar as correções de que precisávamos, visto que nossos problemas não foram corrigidos no branch mainstream.

Na minha opinião, este projeto precisa iniciar um programa de patrocínio, assim como Django e DRF fizeram. Faça as empresas pagarem por todo o lucro que obtêm graças a este projeto incrível e dê esse dinheiro aos desenvolvedores para que trabalhem em tempo integral nisso.

O aipo está ligeiramente quebrado em relação ao pytest atual (outro módulo popular); # 5271 descreve o problema e # 5097 o corrige. Talvez se a versão 4.3 está se tornando muito assustadora, um salto de versão menor para 4.2.2 poderia acumular várias correções menores (# 5271 e outras correções de bugs)? Sei que é provavelmente mais fácil falar do que fazer, mas pode permitir que muitos de nós voltemos ao ciclo de lançamento em vez de manter nossos próprios garfos enquanto aguardamos 4.3. Obrigado por este excelente módulo.

então quais empresas vão patrocinar nosso trabalho? Alguém está interessado? Terei muito interesse em conseguir que algumas empresas apoiem meu tempo para trabalhar com aipo meio período / período integral!

Tenho certeza de que se houvesse uma configuração adequada para doações regulares, seria mais fácil para as empresas apenas se inscrever para um suporte mensal e esquecer. Esta pode ser a fonte de uma renda mais estável do que um simples botão de doação única no paypal. Eu poderia facilmente convencer minha empresa a fazer isso, por exemplo, do que pedir a eles que doem muito de uma vez, ou que os lembrem de fazer uma doação manual regular.

Eu acrescentaria também, para o nosso projeto, o aipo é o único bloqueador que nos impede de atualizar para o python 3.7

um link relacionado: https://tidelift.com/

Acho que o patrocínio é muito possível, mas é preciso plantar a ideia na cabeça das pessoas. Por exemplo, fora deste tópico, ninguém pensa que este projeto pode precisar de suporte, eles apenas baixam e instalam o aipo e pensam que ele simplesmente "existe". Acho que, se vocês tivessem começado uma arrecadação de fundos, muitas empresas doariam.
Eu vi o link de doação no README e contribuí um pouco de uma conta pessoal, mas ainda é muito obscuro para as empresas perceberem. Deve estar bem na frente deles (pelo menos em todas as redes sociais) e deve ter uma chamada adequada para a ação. Por exemplo, se você é um desenvolvedor e sabe que sua empresa depende de aipo, peça ao seu gerente para doar.
Posso dizer que sempre que vejo arrecadação de fundos organizada de projetos de código aberto de que gosto, sempre tento doar ou pelo menos divulgar sua campanha nas redes sociais. Tenho certeza de que muitas pessoas fazem o mesmo.

Eu fiz uma campanha de arrecadação de fundos e acabou falhando muito !! temos as opções opencollective e tide lift abertas no readme. as pessoas interessadas podem doar / patrocinar lá ou me pingar diretamente no meu e-mail.

@auvipy Eu vi que a maioria dos problemas no marco 4.3 foram movidos ou fechados agora.
Estamos planejando fazer uma versão 4.3 em breve?

sim!!! como é muito atrasado !!

Eu estou trabalhando nisso. Espere um RC muito em breve.

Eu fiz uma campanha de arrecadação de fundos e acabou falhando muito !! temos as opções opencollective e tide lift abertas no readme. as pessoas interessadas podem doar / patrocinar lá ou me pingar diretamente no meu e-mail.

Autores de aipo. Eu me tornei um apoiador de https://opencollective.com/celery. Obrigado por sua ferramenta incrível. Suas ferramentas estão me ajudando muito :)

Alguém se opõe ao codinome 4.3 como ruibarbo ?
É uma das minhas faixas favoritas de Selected Ambient Works II.

Se você tiver outras sugestões, anote-as aqui.

Eu gosto disso :)

Kombu 4.3 foi lançado!

Alguém pode dar uma olhada em nosso build do Windows?
Alguns dos testes estão falhando.
Além disso, estão faltando algumas versões do Python, devemos adicioná-las (embora isso não seja um bloqueador).

@thedrow Onde a compilação do Windows está sendo executada? Appveyor?

Alguém pode dar uma olhada em nosso build do Windows?
Alguns dos testes estão falhando.
Além disso, estão faltando algumas versões do Python, devemos adicioná-las (embora isso não seja um bloqueador).

RP aqui https://github.com/celery/celery/pull/5329

Então, 4.3 está pronto para ir agora?

Oi! Você fechou este problema, mas a versão em pypi ainda é 4.2.1. Existe algum lugar onde possamos rastrear o lançamento no pypi? Obrigado.

Oi pessoal,

@seirl Acredito que este problema foi Fixes #5180 .

@auvipy Você poderia, por favor, reabrir esta edição até que 4.3 não seja realmente lançado?
Obrigado!

Que pena, pensei que o fechamento automático seria apenas uma opção para pullee

este foi fechado automaticamente pelo GitHub !!!

@xirdneh yup.

Estou quase terminando o Changelog. Eu ainda tenho que elaborar alguns dos itens e preciso concluir a adição dos itens restantes que não cheguei.

A seção de novidades ainda está incompleta.

Sinta-se à vontade para ajudar no que for possível.

Temos um bloqueador potencial para GA: https://github.com/celery/kombu/issues/1006
Os RCs continuarão conforme planejado.
Alguém com acesso a uma instalação do FreeBSD pode depurar isso?

Olá pessoal. Qualquer hora prevista de chegada?

Acabei de terminar as notas de lançamento do primeiro RC.
Vai ser lançado hoje.

Você tem algum ETA para uma versão estável?

Depois que isso for testado em produção por algumas semanas, declararemos GA.
Em um futuro próximo, melhoraremos nosso processo de lançamento e o documentaremos para que tudo fique mais claro.

RC1 é lançado. : tada:
Por favor, tente em seus ambientes de teste.

Enquanto isso, se alguém puder dar uma olhada em https://github.com/celery/kombu/issues/1006 , https://github.com/celery/kombu/issues/1007 e https: // github. com / celery / kombu / issues / 1004 que são todas regressões do Kombu 4.3, que nos ajudarão a atingir o GA.

Fiz uma possível correção para https://github.com/celery/kombu/issues/1007 em https://github.com/celery/kombu/pull/1009

Como https://github.com/celery/kombu/issues/1004 parecia estar na mesma área, também tentei consertar isso: https://github.com/celery/kombu/pull/1010

Ambos agora estão mesclados.

@lithammer Obrigado!

Como isso foi muito divertido, eu trouxe não uma, mas duas propostas de solução para o último problema (https://github.com/celery/kombu/issues/1006):

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

Fiz uma pequena pausa nas notas de lançamento para escrever https://github.com/celery/py-amqp/pull/258.
Vou prosseguir com nosso documento de novidades.

Eu lancei o Kombu 4.4 e o Celery 4.3.0RC2.
A menos que haja alguma objeção ou correção crítica, este será o último RC.

Acabei de lançar o py-amqp 2.4.3 também.
Ele corrige dois erros graves de desserialização. Não ouvi nada sobre eles na produção.
Provavelmente porque não há mensagens no protocolo AMQP com dois bitmaps consequentes.
As correções existem para completar, pois acho que podem travar o Celery.

Obrigado pelo excelente trabalho @thedrow.

Potencial bloqueador para GA: https://github.com/celery/celery/issues/5371

@thedrow, posso ter algum tempo esta semana para verificar isso. Vou atualizar o problema se puder.

@xirdneh Por favor, atualize se não, e eu cuidarei disso.

@lithammer Se você quiser contribuir mais, vou até conceder a você os direitos de commit :)

Bloqueador definitivo para GA: # 5377

Concluí nosso documento de novidades para este lançamento.

Por favor, revise-o e deixe-me saber se eu esqueci alguma coisa.

@thedrow parece bastante completo e informativo! Porém, uma observação: não tenho certeza se ela foi incluída automaticamente de alguma forma, mas me parece que a lista de contribuidores ainda não foi adicionada.

Eu não gerei a lista de contribuições ainda.
Vou fazer isso antes do GA.

Aqui está uma lista de nossos bloqueadores de lançamento atuais:

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

Potenciais Bloqueadores:

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

@thedrow Acho que https://github.com/celery/celery/issues/5383 também é válido.

Acabei de lançar o Celery 4.3.0rc3.
Isso inclui novos recursos e correções de bugs e alguns bloqueadores resolvidos.

Você sabe quando a versão completa estará disponível?

Quando terminaremos de resolver todos os bloqueadores.

Restou apenas um bloqueador e depois algumas tarefas finais de documentação.

@thedrow parece que o celery / kombu # 1014 foi fechado por um RP baseado em reversão. No entanto, ele não aparece como completo na lista de verificação. Está incompleto porque a palavra-chave unique ainda precisa de suporte?

sim. Vou fazer isso e as tarefas finais de documentação amanhã.

Liberado! : tada:

Obrigado a todos por seus esforços, tempo e habilidades.

A próxima versão, Celery 5, é algo para se entusiasmar.

Eu quero começar a remover python2 do mestre

Posso saber quando o Celery 5 será lançado? Estou muito animado para usar isso.

talvez algumas vezes antes do Natal :)

@auvipy Você pode publicar uma postagem de blog sobre 4.3?

sim, claro, comecei kast ng = ight, mas fiquei ocupado. será concluído até hoje.