Salut à tous,
Puisque @idan a accepté la migration de la communauté oauthlib, en tant qu'équipe, nous devons lister ce dont nous avons besoin pour progresser en tant que véritable communauté. Je suggère de commencer par une petite liste, et faire plaisir à tout le monde, n'hésitez pas à participer en ajoutant des suggestions :-)
Définir/Améliorer le processus de publication :
github's releases
, 2.0.5 dans __init__.py
et 2.0.6 sur pypi
...quelque chose ne va pas à coup sûrTRAVIS_TAG
(voir l'exemple sur https://github.com/thomsonreuters/bottle-oauthlib/blob/master/ setup.py au lieu de notre valeur actuelle codée en dur : https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py ). De plus, j'ai vu que @ib-lundgren est le véritable éditeur du package pypi, il a l'air inactif depuis des années, mais je ne sais pas si c'est un problème.Avenir, feuille de route :
Aussi, une table ronde rapide pourrait être géniale. Je commence les présentations, je travaille actuellement sur une implémentation OAuth2.0 RequestValidator avec bottle, et je n'ai jamais travaillé avec OAuth1.0, ni Django ni Pyramid ni Flask. Cependant, j'essaie d'avoir une bonne connaissance du RFC impliqué ici (oauth2, introspect, révocation, jwt...). Je n'ai pas encore commencé l'intégration d'OpenID, mais cela arrivera bientôt.
Toutes les bonnes idées @JonathanHuot !
Et à quoi pensent les gens :
@JonathanHuot J'essaie un peu de clarifier les choses ici https://github.com/oauthlib/oauthlib/issues/512
Tout ce que je peux faire, il suffit de demander.
sonner :) tout en travaillant sur un PR, j'ai remarqué qu'il n'y a pas de style de codage qui rend les choses parfois difficiles à suivre. J'aimerais travailler là-dessus si vous allez bien. Peut-être en commençant par un problème contenant une proposition et après son acceptation, en commençant par :nail_care: la base de code ?
Salut @MattBlack85 , c'est une bonne idée, tout travail dans ce sens est le bienvenu ! :-)
_re : style de codage_. J'ai trouvé dans les projets sur lesquels j'ai travaillé cela en utilisant autopep8 et yapf, je peux essentiellement laisser les outils nettoyer le style de codage donc je n'ai pas à m'en soucier (sauf dans les cas où la version nettoyée est beaucoup moins utile que de le nettoyer, généralement pour des longueurs de ligne qui seraient plus claires et ne dépasseraient la limite de longueur que d'un caractère ou deux). J'utilise elpy-mode dans Emacs pour rendre cela facile, mais je pense que cela pourrait facilement être fait en ligne de commande et en CI également.
Avoir un .editorconfig
à la racine du dépôt a également été utile.
Juste en pensant que nous voulons probablement fusionner les PR actuellement ouverts avant de transmettre le code à un formateur. Je suis pour pep8/flake8/yapf.
:+1:
??
Je suis un grand fan de garder les choses PEP8.
Commentaire le plus utile
Juste en pensant que nous voulons probablement fusionner les PR actuellement ouverts avant de transmettre le code à un formateur. Je suis pour pep8/flake8/yapf.