O PyPI tem versões estáveis ​​(versões que acreditamos estarem prontas para produção). O branch master que você vinculou acima tem suporte de trabalho em andamento para Python 3. Uma grande quantidade de trabalho foi feita em direção ao suporte de Python 3 e está tomando forma, mas um bug significativo do Python 3 foi encontrado e corrigido apenas sobre um semana atrás (# 1054). Mais testes são necessários antes que ele possa ser considerado pronto para produção.

Por que esses problemas foram encerrados? O README diz que _Supervisor é conhecido por trabalhar com Python 2.4 ou posterior, mas não funcionará em nenhuma versão do Python 3._, o que significa que # 1060 e # 1070 não devem ser fechados.

Por que esses problemas foram encerrados? O README diz que o Supervisor é conhecido por trabalhar com Python 2.4 ou posterior, mas não funcionará em nenhuma versão do Python 3.

Você está citando o README da versão estável atual do Supervisor 3 ( arquivo ). O README dessa versão declara os requisitos dessa versão.

A próxima versão principal, Supervisor 4, incluirá suporte para Python 3. Este é o branch master no git. O README dessa versão foi atualizado para indicar o suporte ao Python 3.

Existe um roteiro para o lançamento da versão 4? Parece não haver problemas em aberto no Python 3. Existe uma maneira de ajudar no teste do branch atual do git?

Eu também estou pronto para ajudar no teste

@tcwalther @palmkevin Obrigado por oferecer ajuda no teste. Seria muito útil se você pudesse tentar exercitar o branch master em Python 3 e 2, tentando tantas opções e comandos quanto possível, e relatando de volta. Você pode relatar em "Encontrei x bug" ou "Usei por x horas e exercitei x recursos e não encontrei um problema". Ambos seriam úteis.

Várias pessoas relataram que ele funciona no Python 3, mas está claro para mim, pelos bugs que descobri depois, que essas pessoas não o estavam testando com muito rigor. Por exemplo, # 1054 é um recurso importante do Supervisor e deveria ter sido relatado. Acabei de começar a digitar os comandos em ordem alfabética e o primeiro que tentei não funcionou de jeito nenhum.

Houve muito progresso em relação ao suporte ao Python 3 nos últimos meses. No momento, não estou ciente de nenhum bug específico do Python 3, por isso não há nenhum no rastreador. Finalmente funcionou o suficiente para que eu comecei a executá-lo no Python 3 agora. Eu gostaria de fazer uma versão compatível com Python 3. No entanto, as pessoas dependem desse software em servidores de produção, por isso é importante termos confiança de que ele realmente funciona. Relatórios de testes bem-sucedidos ajudariam.

Alguns testes básicos do branch master mostram que parece "funcionar" pelo menos um pouco :) Vou testá-lo por um tempo e postar quaisquer problemas que encontrarmos aqui ... ( @tcwalther e eu estamos na mesma turma).

Seguindo @jkp , estamos testando isso em nossa equipe de trabalho (estamos na mesma equipe). Não usamos nenhum comando sofisticado, mas apenas executamos supervisord -c some_config_file em primeiro plano como o ponto de entrada em um contêiner do Docker. Faremos um relatório se encontrarmos algum problema.

@mnaberez IMHO se o teste for mais necessário do que portar o código, pode ser útil lançar versões alpha / beta / rc, então não é necessário buscar o supervisor do git.

Estamos mais perto de um lançamento? Gostaríamos muito de usar o Python 3.

Considere lançar uma versão beta no PyPI para que as pessoas possam testar a compatibilidade do Python3 de uma maneira mais fácil.

Muito Obrigado.

Um pré-lançamento no PyPI vai ajudar muito, obrigado.

Considere lançar uma versão beta no PyPI para que as pessoas possam testar a compatibilidade do Python3 de uma maneira mais fácil.

Você deve conseguir instalar o branch master com pip usando um único comando (consulte Suporte VCS ). Agradeceríamos se você usasse este método, ou uma verificação de git , para economizar aos mantenedores o trabalho extra de empacotar versões não estáveis ​​que serão usadas apenas por testadores.

Mais bugs específicos do Python 3 foram relatados e corrigidos recentemente (por exemplo, abef0a2be35f4aae4a4edeceadb7a213b729ef8d).

Você está citando o README da versão estável atual do Supervisor 3 ( arquivo ). O README dessa versão declara os requisitos dessa versão.

O README e a documentação online (para a versão estável atual) dizem:

O Supervisor funciona com Python 2.4 ou posterior, mas não funciona em nenhuma versão do Python 3.

Essas palavras ainda são um pouco enganosas para mim (na verdade, me assustou e me fez temer se deveria usar o Supervisor). Achei que o Supervisor (em comparação com o Supervisor 3 ) nunca daria suporte ao Python 3. Felizmente, não parece ser o caso ....

@ adah1972 O problema aqui é que não há classificadores de tesouro do Python3 em https://pypi.python.org/pypi/supervisor, portanto, quando os usuários vão para o PyPI, ele informa que o Supervisor _apenas_ executa no Python legado.

O problema aqui é que não há classificadores trove do Python3 em https://pypi.python.org/pypi/supervisor, portanto, quando os usuários vão para o PyPI, ele informa que o Supervisor só roda no Python legado.

O projeto do Supervisor libera apenas versões estáveis ​​do PyPI. Não existe atualmente uma versão estável do Supervisor que suporte Python 3. Tentativas de adicionar suporte a Python 3 foram feitas e estamos muito mais próximos, mas bugs na porta Python 3 continuam a ser encontrados. Outro que quebrou uma funcionalidade importante foi encontrado no início deste mês.

Os classificadores README e Trove que você vê no PyPI estão corretos para a versão estável mais recente. Os classificadores Trove foram atualizados em setup.py para o branch Python 3 e serão adicionados ao PyPI quando uma versão estável dessa versão for feita.

Eu diria que seria suficiente dizer:

O Supervisor funciona com Python 2.4 ou posterior, mas não funciona em nenhuma versão do Python 3.

Parece muito estranho e confuso dizer que não .

Ei @mnaberez ,

Estou trabalhando com @palmkevin no mesmo projeto. Baixamos o supervisor v4.0.0-dev0 e o hospedamos em nosso pypiserver privado.
Estamos usando há cerca de 2 meses em nosso ambiente de desenvolvimento e há algumas semanas agora em alguns ambientes de produção do cliente. Não enfrentamos nenhum problema até agora.

Nós nos comunicamos com o supervisor via xmlrpc e usamos as seguintes funcionalidades:

• desligar
• startProcess
• stopProcess
• reloadConfig
• getProcessInfo
• getAllProcessInfo
• getState
• tailProcessStdoutLog
• readProcessStdoutLog
• getSupervisorVersion

Sabendo disso, espero que possamos encorajá-lo a publicar uma primeira versão de seu pacote para pypi.

@ henkesde92 De onde você tirou a v4.0.0-dev0? Não vejo que haja uma etiqueta ou um ramo para isso.
Você está usando apenas o chefe do branch master?

Mais problemas em execução no Python 3 foram encontrados e marcados . Em pelo menos um caso (# 1178), a interface da web para de funcionar completamente. Agradecemos qualquer ajuda para corrigir esses problemas.

@mnaberez Agora que https://github.com/Supervisor/supervisor/pull/1187 foi mesclado, estamos perto de obter um lançamento? Mesmo um upload beta / rc nos ajudaria muito,

Ajudaria a obter algum foco no # 1110, que sinto que está corrigido, mas é o único problema em aberto com um rótulo ___python 3___ .

Existe a possibilidade de lançar uma versão beta ou rc do supervisor para PyPI? Eu trabalho em um projeto de código aberto que usa o supervisor extensivamente (https://github.com/ansible/awx), e estamos fechando o suporte para Python3, e este é o _um_ item restante que está nos impedindo. Se uma versão estivesse disponível no PyPI, acabaríamos adicionando-a à nossa matriz de teste de integração expansiva, onde implantamos e testamos nosso projeto em uma variedade de distribuições.

Eu ficaria feliz em ajudar a investigar quaisquer questões pendentes remanescentes (como
https://github.com/Supervisor/supervisor/issues/1110) que se relacionam ao suporte py3 e ajudam a levá-lo até a linha de chegada.

1110 Parece acontecer no Python legado também, mas certamente seria útil encontrar sua causa raiz.

@mnaberez Você poderia lançar um beta? Isso nos ajudaria imensamente no teste do suporte ao Python 3.

@mnaberez ,

Um projeto de origem no qual trabalho (https://github.com/ansible/awx) começou recentemente a testar HEAD deste repositório em nossas compilações, pois estamos trabalhando no suporte para distros somente py3. Executamos um conjunto de testes de integração noturno muito completo em várias distribuições Linux. Usamos vários comandos supervisorctl e também usamos RPC: https://github.com/ansible/awx/blob/devel/tools/docker-compose/supervisor.conf

Até agora, não notamos nenhuma regressão em nossos testes de instalações que rodam supervisord sob Python 3.6.6.

Adoraríamos para enviar a próxima versão apontou para um 4.0.0 beta em vez de ter de desembolsar um SHA específica git deste repo.

Adoraríamos lançar a próxima versão apontada para um beta 4.0.0, em vez de ter que fazer um fork de um SHA git específico deste repositório.

Este projeto não libera versões instáveis ​​para PyPI ( observado acima ). Não envie software de produção usando uma versão instável do Supervisor (git sha ou outro). Se fosse adequado para uso com software de produção, seria lançado como uma versão estável. Acho que estamos perto, mas ainda não chegamos lá. Existem vários programas alternativos que fazem o que o Supervisor faz. Se você não puder usar uma versão estável do Supervisor, recomendo escolher uma alternativa em vez de arriscar um ambiente de produção em uma versão instável.

@mnaberez ,

Dado que parece haver várias pessoas neste tópico fazendo _exatamente_ isso em produção (e não relatando problemas) e que não há _notáveis_ problemas abertos relacionados a python3 no rastreador (há https://github.com/Supervisor / supervisor / issues / 1110, embora pareça difícil de reproduzir, baixa gravidade e específico para o uso de supervisorctl tail ), em que ponto você consideraria o supervisor estável em python3 e digno de um lançamento? Existe algum conjunto tangível de critérios que impedem isso?

Dado que parece haver várias pessoas neste tópico fazendo exatamente isso na produção (e não relatando problemas)

Tem havido pessoas usando o Supervisor em Python 3 desde 2014. Por quase todo o tempo, desde então, alguns têm insistido muito abertamente neste rastreador de problemas que ele funciona bem. Um dos mais surpreendentes para mim foi o # 1054. Após anos de reclamações de que funcionou, um comando inteiro foi completamente quebrado para a configuração padrão. Havia problemas semelhantes com a funcionalidade básica, como o registro muito interrompido após anos de relatórios de sucesso. Portanto, embora aprecie e ouça relatos de sucesso, posso não considerá-los tanto quanto faria se não tivesse tido essas experiências.

e que não há problemas abertos notáveis ​​relacionados a python3 no rastreador (há # 1110, embora pareça difícil de reproduzir, com baixa gravidade e específico para o uso de supervisorctl tail)

O rastreador de problemas ficou praticamente livre de bugs do Python 3 por um curto período de tempo, e é possível que o bug do descritor de arquivo inválido seja apenas uma manifestação de um problema maior. Acho que pelo menos é necessário mais investigação antes que seu escopo ou gravidade possam ser entendidos. Há também um monte de problemas marcados como "procura-se ajuda", e gostaria de revisá-los para ter certeza de que são problemas existentes e não causados ​​por alterações no mestre, já que alguns dos rastreamentos são do mestre.

em que ponto o que você considera supervisor estável em python3 e digno de um lançamento? Existe algum conjunto tangível de critérios que impedem isso?

Vou tentar revisar os problemas mencionados acima novamente (descritor de arquivo incorreto e ajuda necessária) e também fazer alguns testes mais rigorosos, antes que seja enviado para fora. Não sou o único committer capaz de lançar este software, mas sou o mais ativo ultimamente. Eu sou um dos principais autores dos patches do Python 3 neste projeto - eu mesmo quero uma versão estável e compatível com o Python 3. Ao mesmo tempo, quero ter certeza de que isso não derrubará vários sites de produção ou gerará uma tempestade de novos problemas de suporte. Como eu disse acima, acho que está perto, mas não recomendo executar uma versão instável do Supervisor em produção.

então ele pode ser lançado como beta (4.0.0b) no PyPI e até mesmo marcado como Python 3 apenas usando o especificador de versão PEP 440

setup(
    ...
    python_requires='>=3',
    ...
)

dessa maneira:

• todas as pessoas que desejam usar o supervisor no projeto Python 3 terão acesso muito mais fácil a ele, enquanto ele ainda será marcado como considerado instável (na verdade, pipenv para um, não instalará o beta a menos que explicitamente configurado para)
• mais usuários (multidão python 3) -> mais recursos testados -> mais confiança no suporte Python 3
• os usuários atuais (Python 2) não serão afetados negativamente

Pessoalmente, acredito que deve ser mais rápido fazer a triagem dos problemas relatados por novos usuários do Python 3 do que esperar que o proprietário / contribuidor do projeto encontre tempo suficiente para pensar e testar todos os cenários possíveis.

Também gostaria de observar que vendo como o Python 2 EoL está se fechando (1o de janeiro de 2020), o suporte ao Python 3 não é mais uma opção, mas um requisito para manter este projeto vivo, por isso proponho esta solução.

A cobertura atual é de 89%: https://travis-ci.org/Supervisor/supervisor/jobs/476482824 aumentá-la para 95-99% faria você se sentir mais confortável para fazer um lançamento? :pensamento:

Patches para adicionar cobertura de teste são bem-vindos e ajudariam a aumentar a confiança.

Desesperado por um lançamento de suporte Python 3, por favor ... :)

A documentação não deveria ser atualizada para dizer que ainda não está disponível no python 3? ou modificado para mostrar como instalá-lo em um sistema python 3?
incapaz de instalar o supervisor em python 3 # 1205

A documentação não deveria ser atualizada para dizer que ainda não está disponível no python 3?

A documentação para a versão de lançamento atual (3.3.5), que está publicada em supervisord.org , já diz o seguinte:

http://supervisord.org/introduction.html#platform -requirements
"O Supervisor funciona com Python 2.4 ou posterior, mas não funciona em nenhuma versão do Python 3."

@ henkesde92 De onde você tirou a v4.0.0-dev0? Não vejo que haja uma etiqueta ou um ramo para isso.
Você está usando apenas o chefe do branch master?

@stevecj Não há tag ou branch, está no master, mas o número da versão vem de setup.py que por sua vez o lê de supervisor/version.txt .

Fechando essa edição ... Já se passaram dois anos sem quase nenhum progresso.

Com apenas 295 dias restantes para o fim da vida útil do Python 2, essa porta não vai acontecer a tempo.

@cclauss Talvez não haja progresso porque já funciona? Eu realmente não entendo por que ele não é empacotado apenas para Python 3 e permite que os usuários o usem e relatem os problemas à medida que são descobertos. Certamente essa é uma das melhores maneiras de desenvolver software de código aberto? Deixar o projeto morrer porque ninguém tem confiança para lançar uma versão do Python 3 parece precioso. Obviamente, muito trabalho árduo foi canalizado para este projeto.

FWIW, tenho usado "4.0.0-dev0" com Python 3.5 por quase 12 meses sem nenhum problema me afetando. No entanto, admito que não estou testando todas as funcionalidades, mas parece bom o suficiente para, pelo menos, deixar a comunidade começar a usá-lo corretamente.

@mnaberez @cclauss Por que você se opõe ao lançamento de uma versão beta? Você está ativamente desencorajando os usuários a testarem o suporte ao Python 3, pois muitas organizações têm políticas de conformidade que tornam a extração do GitHub proibida.

Isso também deve ser reaberto.

Reabrindo uma vez que ainda parece haver um interesse significativo neste assunto.

Eu diria para sair da caixa “nós apenas lançamos versões estáveis” e lançar uma versão alfa ou beta pública em pypi para a transição py2 -> py3 por causa deste software fantástico.

Dessa forma, você permite que os usuários decidam usar versões alfa ou beta e todos sabem o que essa terminologia significa.

O teste será muito mais fácil para muitos usuários e o progresso pode ser feito em um curto prazo quando os problemas são adicionados.

Dessa forma, você permite que os usuários decidam usar versões alfa ou beta e todos sabem o que essa terminologia significa.

Durante a maior parte de sua vida, este projeto usou um esquema de controle de versão confuso. Foi muito antes do meu envolvimento com a embalagem, então não posso responder por quê. Versões estáveis ​​tinham nomes alfa / beta estranhos como "3.0a3" ou "3.0b2". Talvez eles fossem inicialmente alfa / beta, mas continuaram por anos e eram estáveis ​​- eles não tinham problemas significativos e nenhuma quebra de BC entre eles que eu me lembre. Versões com esses nomes foram empacotadas até mesmo pelas principais distribuições como estáveis. Essa longa história torna difícil para nós agora comunicarmos efetivamente as versões não estáveis ​​reais aos usuários existentes.

@mnaberez ,

Parece que o último exemplo disso (pelo menos, pelo que posso dizer no PyPI) foi https://pypi.org/project/supervisor/3.0b2/

... o que foi há quase 6 anos. Também coincide com a mudança de supervisor2 para supervisor3, portanto, a noção de pré-lançamentos é um esquema de versão principal com o qual os usuários devem estar familiarizados, historicamente.

Isso poderia ser resolvido por uma postagem na lista de e-mails explicando que uma nova versão alpha / beta / rc foi lançada com suporte oficial para Python3 (incluindo instruções sobre como relatar quaisquer problemas encontrados?) Talvez chamando de forma muito explícita em http: //supervisord.org?

Parece-me que há várias pessoas neste tópico que já estão enviando software de produção usando 4.0.0dev . As distribuições estão até mesmo empacotando-o de (presumo) HEAD .

https://koji.fedoraproject.org/koji/buildinfo?buildID=1203704

Como mantenedor de pacotes de software de código aberto, eu acho que essa situação seria muito menos desejável do que apenas distribuir um pré-lançamento, ouvir diretamente dos usuários e corrigir quaisquer bugs que existam.

@mnaberez Uma vez que a principal preocupação é que as versões estáveis ​​costumavam ser pós-fixadas com a ou b , você poderia usar rc para pré-lançamentos reais?

Novamente, muitas pessoas estão bloqueadas neste 🙁

... o que foi há quase 6 anos. Também coincide com a mudança de supervisor2 para supervisor3, portanto, a noção de pré-lançamentos é um esquema de versão principal com o qual os usuários devem estar familiarizados, historicamente.

Ele usava o estranho esquema de versão a / b para todas as versões de 2007-2011. Não foram apenas alguns pré-lançamentos.

Talvez o candidato a lançamento rc seja melhor? Mais uma vez, 2007-2011 foi há mais de 8 anos.

@mnaberez A versão atual em master funciona muito bem com Python3, a comunidade só precisa de um lançamento, embora não seja perfeito. Faz sentido se o bug está segurando isso também aparece no Python2 como algumas pessoas apontam.

Todos os meus colegas membros da comunidade Plone e acho que os da Pirâmide também estão ansiosos por isso. Por favor, você pode liberar? Um alfa estaria perfeitamente bem.
Muito obrigado!

/ cc @mcdonc @tseaver @stevepiercy @zupo @gforcada @pbauer @jensens @tisto

Nunca haverá perfeição em software. O supervisor está por perto, embora haja bugs abertos no rastreador de problemas. Para fazer as coisas, seria bom marcar os problemas usando um rótulo adicional, como "bloqueador de liberação" (junto com "procura-se ajuda" existente?) Ou (talvez melhor) usar o recurso de marco do Githubs, para que pessoas das comunidades e empresas com habilidades de desenvolvimento, o supervisor pode resolver os problemas e fornecer patches.

Atualmente, o maior problema para a maioria das pessoas não é a estabilidade, mas a falta do lançamento do Python 3. Uma versão é diferente de instalar via VCS e pode ser empacotada e distribuída de maneira diferente, ajustando-se aos fluxos de trabalho de operações atuais. Portanto, mesmo que eu me repita aqui, essa incerteza é um grande problema.

@sneridagh os únicos mantenedores do PyPI são @mcdonc e @mnaberez. Outros não podem fazer nada para liberar o Supervisor no PyPI.

Os principais desenvolvedores do Pyramid lançam versões alfa e beta , e funciona bem para nós. Comunicamos lançamentos através dos canais habituais: lista de correio , Twitter e README.

Não vejo nenhum problema em fazer o mesmo com o Supervisor e acho que seria benéfico para seu desenvolvimento posterior. Caramba, pode até haver outro mantenedor à espreita para dividir o fardo.

Mesmo nós tentamos usar a versão master atual. E funciona muito bem.
Espero que isso possa ser lançado como um pacote beta, pois podemos usá-lo diretamente, em vez de criar um fork do repo e instalar manualmente. Em breve hospedarei este pacote em um novo repositório PIP. Muitos de vocês podem retirar o pacote pip sozinho. Será atualizado aqui em breve.

Em breve hospedarei este pacote em um novo repositório PIP. Muitos de vocês podem retirar o pacote pip sozinho. Será atualizado aqui em breve.

Uma rápida pesquisa de PyPI mostra que pelo menos uma pessoa já fez isso:

https://pypi.org/project/supervisor-lrn/

Nota: o autor deste pacote não está envolvido com o projeto Supervisor. Eu não baixei ou verifiquei este pacote.

Fechando em favor do fork compatível com Python 3 https://pypi.org/project/supervisor-lrn/

@cclauss sério?

Ok, é uma pena, mas depois de mais de 10 anos usando o supervisor, mudaremos para o pm2 ou o systemd.

Adeus e obrigado pelos peixes.

Eu realmente não entendo a forma como os mantenedores do projeto decidiram
faça isso. É realmente uma pena, tanto faz. A comunidade está apenas pedindo
para uma versão beta para ajudar a testar e finalizar o suporte a python 3. Em vez de,
você aponta uma bifurcação para as pessoas.
Vou mudar para outra coisa também.

Domingo, 24 de março de 2019, 14h44 Víctor Fernández de Alba, <
notificaçõ[email protected]> escreveu:

@cclauss https://github.com/cclauss sério?

Ok, é uma pena, mas depois de mais de 10 anos usando o supervisor, vamos
mude para usar pm2 ou systemd.

Adeus e obrigado pelos peixes.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Supervisor/supervisor/issues/1060#issuecomment-475960800 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAGU8E33aSZ3ocMQoP7evXh7WWEq4Gv_ks5vZ4E1gaJpZM4SInJR
.

Por favor, pare de encerrar o problema @cclauss. É claro que há interesse tanto da comunidade quanto de @mnaberez.

@cclauss sério?

Ok, é uma pena, mas depois de mais de 10 anos usando o supervisor, mudaremos para o pm2 ou o systemd.

@cclauss , a pessoa que fecha repetidamente este tíquete, não faz parte do projeto do Supervisor. Ele pode fechá-lo porque o abriu originalmente.

Como ainda há uma discussão ativa aqui, irei reabri-la (novamente).

@mnaberez ok, isso causou um pouco de confusão, pensei que ele estava no comando também. Talvez devêssemos passar para outro assunto.

Qual é o bloqueador que está prendendo você para a liberação, então?

@mnaberez E a mesma discussão neste ticket já se repetiu muitas vezes e não está indo em uma direção (positiva).

Talvez você e alguns outros mantenedores possam explicar ou reconsiderar seu ponto de vista sobre este problema e então fechá-lo?

Vários usuários e outros mantenedores do OSS já pediram aqui um lançamento oficial do rc. Agora, alguém não relacionado ao projeto do supervisor fez isso. Não acho que isso seja benéfico para o projeto do Supervisor, mas compreensível se você não estiver fazendo isso.

É realmente uma pena, tanto faz. A comunidade está pedindo apenas uma versão beta para ajudar a testar e finalizar o suporte ao python 3. Em vez disso, você aponta uma bifurcação para as pessoas.

Observe que indiquei o pacote de terceiros existente apenas em resposta a outro usuário comentando sobre a criação de um pacote . Minha intenção era apenas evitar que aquela pessoa fizesse um trabalho que já havia sido feito.

Talvez você e alguns outros mantenedores possam explicar ou reconsiderar seu ponto de vista sobre este problema e então fechá-lo?

Pretendo lançar um pacote oficial do Supervisor 4.0.0 com suporte para Python 3 em 2 semanas. É improvável que o lançamento seja chamado de alfa / beta pelos motivos históricos observados acima, mas pode ser chamado de rc conforme sugerido por @ofek , @ryanpetrello e outros. No entanto, já se passaram vários meses desde que fiz os comentários de estabilidade acima, e nenhum novo problema do Python 3 foi relatado desde então. Eu também tenho usado durante esse tempo e não tive novos problemas. Dado tudo isso e o número de pessoas relatando que funciona para elas, pode simplesmente ser chamado de 4.0.0. Fecharei este tíquete quando for liberado para o PyPI.

Qual é o bloqueador que está prendendo você para a liberação, então?

No momento, não há um bloqueador para isso, exceto eu gostaria de primeiro fazer uma versão de recurso 3.4.0 que já comecei. Pretendo fazer isso na próxima semana e 4.0.0 na semana seguinte.

Por favor, mantenha isto aberto, nossos projetos realmente precisam que isso aconteça

Supervisor 4.0.0 (pacote PyPI; suporta Python 3.4+ e 2.7)