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:
github's releases
, 2.0.5 em __init__.py
e 2.0.6 em pypi
... algo errado com certezaTRAVIS_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.Futuro, roteiro:
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.
Todas as grandes ideias @JonathanHuot!
E o que as pessoas pensam sobre:
@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.
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.