Fabric: Considere alterar o pino de requisito Paramiko quando o Paramiko 2.0.x estiver definitivamente estável

Criado em 30 abr. 2016  ·  19Comentários  ·  Fonte: fabric/fabric

  • Lançamos 1.10.3 e 1.11.1 com fixação explícita de paramiko<2 para evitar que os ambientes das pessoas sejam atualizados / interrompidos inesperadamente há um tempo.
  • Paramiko 2.0 já foi lançado, mas está fresco, provavelmente alguns bugs precisam ser corrigidos.
  • Seria _agradável_ permitir que as pessoas atualizem para Paramiko 2.0 no Fabric 1 se elas quiserem explicitamente - no entanto, não vejo uma maneira no setuptools / pip de fazer isso

    • por exemplo, a funcionalidade extras_require não permite que você substitua o mesmo pacote / versão conforme especificado em install_requires , então não podemos fazer pip install fabric[paramiko-2] ou nada.

    • Espero que haja algo mais que possamos fazer e que estou perdendo, como setup.py parâmetros CLI - mas eles também não são uma panacéia, pois não funcionam com rodas ou qualquer outro método de instalação não-sdist

    • Eu também gostaria de evitar ter que criar uma segunda entrada terrível no PyPI / setup.py, como fabric-paramiko2 embora essa seja outra opção.

  • Dado que Paramiko 2 é API compatível com Paramiko 1, nós _podemos_ querer apenas aumentar o pino da versão para paramiko<3 em versões posteriores do Fabric, para que as pessoas possam continuar recebendo correções de bug / segurança / etc da linha Paramiko 2.x

    • Se fizermos isso, precisamos remover a chamada Crypto.atfork em decorators.py (consulte # 1460) e certifique-se de que nenhuma outra bagagem PyCrypto permaneça

    • Isso sempre terá uma chance de quebrar para pessoas que não conseguem obter a roda estática Cryptography.io tudo-em-um; eles irão atualizar o Fabric e então ele explodirá se eles não tiverem libffi-dev ou openssl-dev. Portanto, seria inteiramente sensato nunca realmente desfazer esse alfinete, em vez de fazer com que as pessoas usassem o Fabric 2 depois de retirado.

Packaging Support

Comentários muito úteis

Grump, isso é irritante - obrigado pela notícia, @hostep. (Não estou tentando ser sarcástico, mas - também surpreso que MacPorts ainda esteja em uso, todo mundo que eu conheço mudou para o Homebrew anos atrás. Bom lembrete de que "top of mind"! = "O único jogo da cidade", eu acho :))

Eu tirei um pequeno 1,12 por capricho na noite passada (outro bom lembrete para mim mesmo: pare de usar números de versão literais ao discutir o roteiro - apenas diga "um próximo lançamento de recurso" ou etc) e não fiz essa alteração, mas ainda quero faça isso logo, então provavelmente o próximo lançamento menor.

Todos 19 comentários

Talvez considere um estado intermediário, onde para um ou dois lançamentos, o fabric setup.py permite paramiko>=2 e paramiko<2 , e as pessoas receberão cryptography por padrão, mas pode forçar a versão PyCrypto antiga se necessário. Depois de queimar um pouco, você pode mover setup.py para exigir paramiko>=2 .

Não tenho certeza se algum dia faria o Fabric 1.x exigir paramiko> = 2, planejo salvá-lo para o Fabric 2.x. Depende da aceitação do Fabric 2.x assim que for lançado, eu acho.

Você está certo ao dizer que voltar ao "Não me importo, paramiko 1 ou 2 está ok" ainda pode ser resolvido permitindo que as pessoas façam o downgrade manualmente de seus Paramiko. a fixação foi principalmente uma tentativa de evitar uma enxurrada de relatórios "onoz u quebrou minha construção". Conseguimos alguns, mas não uma tonelada, se isso foi devido ao meu alfinete ou não, ninguém sabe.

@bitprophet FWIW, tenho alguns dataz! Nas últimas 2 semanas (isso inclui alguns dias antes do lançamento do paramiko 2.0), aqui estão as versões mais baixadas do Paramiko do PyPI:

| Versão | Downloads |
| --- | --- |
| 1.16.0 | 411903 |
| 2.0.0 | 308131 |
| 1.17.0 | 77360 |
| 1.15.2 | 47677 |
| 1.15.1 | 23893 |

Para mim, esse número muito grande de instalações 2.0 indica que provavelmente é seguro e, portanto, remover o limite de <2 é desnecessário, para a maioria das pessoas funcionará bem (ou será facilmente corrigido), e para aqueles que podem não basta fazer um pip install paramiko<2 antes que pip install fabric o conserte.

Seria possível pelo menos usar um marcador de ambiente para dizer ao fabric para usar paramiko> 2 para PyPy pelo menos, onde o status quo atual é que o fabric não vai instalar de qualquer maneira?

@alex tardiamente, você quis dizer "remover o limite de <2 é seguro"? (em vez de "desnecessário"): D

@Julian Presumo que você queira dizer outras poucas linhas de "alter install_requires base no intérprete atual"? Não se opõe a isso de improviso. (Embora esses hacks do IIRC parem de funcionar com rodas, estamos começando a fugir deles ...?)

Uhhh, sim, eu quis dizer que é seguro.

@bitprophet para as rodas você faz a mesma coisa, apenas em extras_require com um marcador de ambiente.

Basicamente, você esfrega a barriga de @dstufft e um gênio aparece.

(Exemplo mais sério: https://github.com/Julian/jsonschema/blob/master/setup.py#L25 mas você substitui python_version por python_interpreter para despachar nisso).

Vou tentar colocar isso em um PR para que você possa ver como fica, a menos que você esteja prestes a fazer isso acontecer de alguma forma?

Oh, legal, eu só me lembro vagamente de aprender sobre essas coisas um tempo atrás. Claramente, então esqueci. Definitivamente, estou disposto a fazer isso se for ajudar algumas pessoas e não prejudicar a maioria. Um PR seria apreciado.

Re: problema externo, acho que neste ponto estou tentando empurrar o pino para <3 no Fabric 1.12+ (junto com os outros expurgos de criptografia mencionados anteriormente, embora eles precisem se tornar condicionais, a menos que eu queira faça paramiko>=2,<3 , que eu sou menos a favor. Vou ver como as coisas ficam feias quando eu cutucar isso e tento garantir que o mesmo ramo do Fabric passe nos testes em dois venvs separados, um com Crypto e Paramiko 1, o outro sem criptografia e paramiko 2)

Oi, pessoal

Pequeno acréscimo a esta discussão:
Usamos Macports para instalar a porta Fabric, que depende da porta Paramiko em nossas estações de trabalho macOS.
Mas recentemente a Macports decidiu atualizar o Paramiko da versão 1.16.0 para 2.0.1 e quando agora

➜ 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

Eu o contornei fazendo o downgrade do Paramiko para a versão 1.16.0 usando Macports, o que era um pouco complicado de fazer manualmente, mas eventualmente o fiz funcionar novamente.

Eu acho que isso é um erro dos Macports, eles deveriam ter esperado para atualizar o Paramiko em sua árvore até que o Fabric fosse compatível.

De qualquer forma, seria ótimo se uma nova versão do Fabric pudesse ser lançada com suporte para Paramiko> 2.0 para que possamos fazer tudo funcionar novamente usando Macports com as versões mais recentes de todas as portas.

Grump, isso é irritante - obrigado pela notícia, @hostep. (Não estou tentando ser sarcástico, mas - também surpreso que MacPorts ainda esteja em uso, todo mundo que eu conheço mudou para o Homebrew anos atrás. Bom lembrete de que "top of mind"! = "O único jogo da cidade", eu acho :))

Eu tirei um pequeno 1,12 por capricho na noite passada (outro bom lembrete para mim mesmo: pare de usar números de versão literais ao discutir o roteiro - apenas diga "um próximo lançamento de recurso" ou etc) e não fiz essa alteração, mas ainda quero faça isso logo, então provavelmente o próximo lançamento menor.

FWIW, nós (FreeBSD) enfrentamos o mesmo problema e tivemos que criar uma porta paramiko1 e um pacote para o py-fabric depender. Veja também:

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

TLDR: dependências <= e == são extremamente dolorosas / irritantes e criam mais problemas do que pretendem resolver.

Há muito menos dor para os usuários downstream e empacotadores / portadores quando os upstreams apenas testam proativamente contra as versões mais recentes de suas dependências (em desenvolvimento, antes dos lançamentos é a melhor hora para fazer isso) e não prescreva ou restrinja o controle de versão de dependência, a menos que existem versões que quebram explicitamente a compatibilidade.

Mesmo nesse caso, a limitação é apenas temporária, e apenas se um lançamento for feito enquanto está quebrado, e apenas enquanto o (s) autor (es) das dependências é / são notificados e até que as correções sejam feitas.

O bônus desse método é que ele ensina upstreams (e upstreams de upstreams) que as decisões que eles tomam realmente afetam seus usuários na prática (não apenas na teoria) e, com esse conhecimento, minimiza a probabilidade de isso acontecer novamente no futuro.

Para adicionar um pouco mais de informações sobre o problema dos Macports, parece que foi corrigido porque eles adicionaram um patch durante a instalação que altera o requisito do Paramiko de <2.0 para <3.0
Agora executamos Fabric v1.12.0 e Paramiko v2.0.2 em nossas estações de trabalho macOS e não temos problemas com isso.

@hostep Obrigado por destacar isso

@hostep De fato, houve momentos em que substituí *_requires especificações (de <= / == para >= ou '' ) no FreeBSD portas, se o conjunto de testes foi aprovado com uma versão posterior da dependência. No entanto, isso depende do incrível dos testes, então pode ser arriscado e, embora sejamos um downstream do Fabric, também não gostamos de quebrar nossos ambientes de usuário (downstream) :)

Mais atualizações de números ... visão geral dos últimos 6 meses:

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

e nas últimas 2 semanas:

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

Paramiko 2.0.x agora facilmente metade de todos os downloads. E eu estou me perguntando quanto dos outros 50% são devido a este ticket não ter sido mesclado :) descobriremos em breve!

Acho que vou executar isso e apresentá-lo como Fab 1.13.0.

Revisitei o que @Julian e eu discutimos há muito tempo, mas que a magia extras_require só parece necessária se eu quiser limitar a mudança para PyPy; neste ponto, estou apenas fazendo o bit "permitir Paramiko <3" no atacado ...

Existe PyPI

Gah, é claro que esqueci o ingresso de irmão, # 1462! 1.13.1 a caminho ... EDITAR: e, mesclado / lançado.

Viva!

Em 9 de dezembro de 2016 20:14, "Jeff Forcier" [email protected] escreveu:

Gah, é claro que esqueci a passagem de irmão, # 1462
https://github.com/fabric/fabric/pull/1462 ! 1.13.1 a caminho ...

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/fabric/fabric/issues/1461#issuecomment-266111875 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAUIXlbJBlS0po_zKgQsUp7-y7I7WgbTks5rGbajgaJpZM4ITeNm
.

Esta página foi útil?
0 / 5 - 0 avaliações