Oauthlib: Migração para a comunidade oauthlib

Criado em 28 jan. 2018  ·  10Comentários  ·  Fonte: oauthlib/oauthlib

Olá a todos,

Uma vez que @idan aceitou a migração da comunidade oauthlib, como uma equipe, devemos listar o que precisamos para progredir como uma verdadeira comunidade. Sugiro começar com uma pequena lista e, por favor, qualquer pessoa sinta-se à vontade para participar adicionando qualquer sugestão :-)

Definir / melhorar o processo de liberação:

  • [x]: Tagging
    Números de lançamentos errados: temos 2.0.3 em github's releases , 2.0.5 em __init__.py e 2.0.6 em pypi ... algo errado com certeza
  • [x]: Publicação
    Eu recomendo continuar a usar o Travis para publicação, no entanto, poderíamos definir a versão diretamente usando a variável de ambiente TRAVIS_TAG (veja o exemplo em https://github.com/thomsonreuters/bottle-oauthlib/blob/master/ setup.py em vez de nosso valor codificado atual: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py). Além disso, eu vi @ ib-lundgren é o editor real do pacote pypi, ele parece inativo há anos, mas não sei se isso é um problema.
  • [x]: Documentação
    O README precisa ser atualizado com o emblema atualizado para a URL do repositório travis-ci.org (o proprietário deve habilitá-lo, AFAIK), e também adicionar um emblema para a construção da https://readthedocs.org / projects / oauthlib / builds / 6483131 /
    FEITO EM : https://github.com/oauthlib/oauthlib/pull/520
  • [x]: Comunicação
    Não há objeção em continuar usando os problemas do github e do Google+ , no entanto, parece um pouco desatualizado. Além disso, o canal de IRC #oauthlib está vazio, ~ imaginando se poderíamos criar uma sala de Slack se tiver interesse? ~
    CONCLUSÃO : o gitter veio em socorro. Sinta-se à vontade para entrar em https://gitter.im/oauthlib/Lobby

Futuro, roteiro:

  • []: Fazer lavagens periódicas de insetos pode ser benéfico

Além disso, uma mesa redonda rápida pode ser ótima. Eu começo as introduções, estou atualmente trabalhando em uma implementação de OAuth2.0 RequestValidator com bottle, e nunca trabalhei com OAuth1.0, nem Django, nem Pyramid, nem Flask. No entanto, estou tentando ter um bom conhecimento sobre a RFC envolvida aqui (oauth2, introspect, revocation, jwt ...). Ainda não comecei a integração do OpenID, mas ela chegará em breve.

Comentários muito úteis

Só pensando que provavelmente queremos uma execução mesclando os PRs abertos no momento antes de passar o código por um formatador. Eu sou totalmente a favor de pep8 / flake8 / yapf.

Todos 10 comentários

Todas as grandes ideias @JonathanHuot!

E o que as pessoas pensam sobre:

  • Limpando alguns dos galhos antigos.
  • Começar a usar os marcos do GitHub para planejar lançamentos (feliz em fazer uma primeira execução, por exemplo, 3.0, 3.1, 4.0).
  • Planejando descartar o suporte para Python 2 em uma das versões principais (talvez 4.0).
  • Apresentando anotações de tipo (depois de abandonar o Python 2).
  • Apresentando um estilo de codificação.

@JonathanHuot Estou tentando coisas claras um pouco aqui https://github.com/oauthlib/oauthlib/issues/512

Qualquer coisa que eu possa fazer é pedir.

entrando :) enquanto trabalhava em um PR, percebi que não há um estilo de codificação que torne as coisas às vezes difíceis de seguir. Eu gostaria de trabalhar nisso se vocês estiverem bem. Talvez começando com um fascículo contendo uma proposta e depois sendo aceito, passando para: nail_care: the codebase?

Olá @ MattBlack85 , é uma boa ideia, qualquer trabalho neste sentido é bem-vindo! :-)

_re: estilo de codificação_. Descobri em projetos em que trabalhei usando autopep8 e yapf, posso basicamente deixar o ferramental limpar o estilo de codificação, então não preciso me preocupar com isso (exceto nos casos em que a versão limpa é muito menor útil do que não limpá-lo, geralmente para fazer com comprimentos de linha que seriam mais claros e só excedem o limite de comprimento por um caractere ou dois). Eu uso o modo elpy no Emacs para tornar isso fácil, mas suspeito que poderia ser feito facilmente na linha de comando e CI também.

Ter um .editorconfig na raiz do repo também foi útil.

Só pensando que provavelmente queremos uma execução mesclando os PRs abertos no momento antes de passar o código por um formatador. Eu sou totalmente a favor de pep8 / flake8 / yapf.

: +1:

👍

Eu sou um grande fã de apenas manter as coisas PEP8.

Se não houver objeções, declaro que esta tarefa foi cumprida 🍾

A nova comunidade lançou um patch 2.0.7 e uma versão secundária 2.1.0 e estamos trabalhando para uma versão 3.0.0 principal.

Não hesite em contribuir e participar neste novo lançamento emocionante!

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

Questões relacionadas

thedrow picture thedrow  ·  31Comentários

JonathanHuot picture JonathanHuot  ·  26Comentários

ggiill picture ggiill  ·  7Comentários

potiuk picture potiuk  ·  14Comentários

ryarnyah picture ryarnyah  ·  3Comentários