Oauthlib: Migration vers la communauté oauthlib

Créé le 28 janv. 2018  ·  10Commentaires  ·  Source: oauthlib/oauthlib

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 :

  • [x] : Marquage
    Mauvais numéros de versions : nous avons 2.0.3 sur github's releases , 2.0.5 dans __init__.py et 2.0.6 sur pypi ...quelque chose ne va pas à coup sûr
  • [x] : Édition
    Je recommanderais de continuer à utiliser Travis pour la publication, mais nous pourrions définir la version directement en utilisant la variable d'environnement TRAVIS_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.
  • [x] : Documentation
    README doit être mis à jour avec le badge mis à jour pour l'URL du référentiel travis-ci.org (le propriétaire doit l'activer, AFAIK), et également ajouter un badge pour la construction de la https://readthedocs.org /projects/oauthlib/builds/6483131/
    FAIT DANS : https://github.com/oauthlib/oauthlib/pull/520
  • [x] : Communication
    Aucune objection à continuer à utiliser les problèmes de github et Google+ , cependant cela semble un peu dépassé. De plus, le canal IRC #oauthlib est vide, ~vous vous demandez si nous pourrions créer une salle Slack si cela vous intéresse ?~
    CONCLUSION : Gitter est venu à la rescousse. N'hésitez pas à nous rejoindre sur https://gitter.im/oauthlib/Lobby

Avenir, feuille de route :

  • [ ] : Faire des nettoyages périodiques des insectes pourrait être bénéfique

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.

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.

Tous les 10 commentaires

Toutes les bonnes idées @JonathanHuot !

Et à quoi pensent les gens :

  • Nettoyage de quelques vieilles branches.
  • Commencer à utiliser les jalons de GitHub pour planifier les versions (heureux de faire un premier essai sur, par exemple, 3.0, 3.1, 4.0).
  • Prévoyez d'abandonner la prise en charge de Python 2 dans l'une des versions majeures (4.0 peut-être).
  • Présentation des annotations de type (après avoir abandonné Python 2).
  • Présentation d'un style de codage.

@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.

Si aucune objection, je déclare cette tâche terminée

La nouvelle communauté a publié un correctif 2.0.7 et une version mineure 2.1.0 et nous travaillons à une version majeure 3.0.0 .

N'hésitez pas à participer et à participer à cette nouvelle version passionnante !

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

JonathanHuot picture JonathanHuot  ·  15Commentaires

jcampbell05 picture jcampbell05  ·  14Commentaires

prudnikov picture prudnikov  ·  11Commentaires

ViktorHaag picture ViktorHaag  ·  11Commentaires

ggiill picture ggiill  ·  7Commentaires