Oauthlib: Migration zur oAuthlib-Community

Erstellt am 28. Jan. 2018  ·  10Kommentare  ·  Quelle: oauthlib/oauthlib

Hallo allerseits,

Da @idan die Migration der oauthlib-Community akzeptiert hat, sollten wir als Team auflisten, was wir brauchen, um als echte Community voranzukommen. Ich schlage vor, mit einer kleinen Liste zu beginnen, und bitte alle, fühlen Sie sich frei, mitzumachen, indem Sie Vorschläge hinzufügen :-)

Freigabeprozess definieren/verbessern:

  • [x] : Tagging
    Falsche Veröffentlichungszahlen: wir haben 2.0.3 auf github's releases , 2.0.5 auf __init__.py und 2.0.6 auf pypi ... mit Sicherheit ist etwas nicht in Ordnung
  • [x] : Veröffentlichung
    Ich würde empfehlen, Travis weiterhin für die Veröffentlichung zu verwenden, aber wir könnten die Version direkt mithilfe der Umgebungsvariablen TRAVIS_TAG (siehe Beispiel unter https://github.com/thomsonreuters/bottle-oauthlib/blob/master/ setup.py anstelle unseres aktuellen hartcodierten Werts: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py ). Außerdem habe ich gesehen, dass @ib-lundgren der eigentliche Herausgeber des Pypi-Pakets ist, er sieht seit Jahren inaktiv aus, aber ich weiß nicht, ob es ein Problem ist.
  • [x] : Dokumentation
    README muss mit dem aktualisierten Abzeichen für die travis-ci.org-Repository- URL aktualisiert werden (Besitzer muss es aktivieren, AFAIK) und auch ein Abzeichen für den Dokumentations-Build hinzufügen, da es seit langer Zeit fehlschlägt: https://readthedocs.org /projects/oauthlib/builds/6483131/
    FERTIG IN : https://github.com/oauthlib/oauthlib/pull/520
  • [x] : Kommunikation
    Es gibt keine Einwände, Github-Probleme und Google+ weiterhin zu verwenden, es scheint jedoch etwas veraltet zu sein. Außerdem ist der #oauthlib-IRC-Kanal leer, ~fragt sich, ob wir bei Interesse einen Slack-Raum erstellen könnten?~
    SCHLUSSFOLGERUNG : Gitter kam zur Rettung. Melden Sie sich gerne unter https://gitter.im/oauthlib/Lobby

Zukunft, Fahrplan:

  • [ ] : Regelmäßige Wanzenwaschungen könnten von Vorteil sein

Auch ein schneller runder Tisch könnte toll sein. Ich beginne mit den Einführungen, arbeite derzeit an einer OAuth2.0 RequestValidator-Implementierung mit Bottle, und ich habe noch nie mit OAuth1.0, weder Django noch Pyramid oder Flask gearbeitet. Ich versuche jedoch, gute Kenntnisse über den hier beteiligten RFC zu haben (oauth2, introspect, revocation, jwt ...). Ich habe noch nicht mit der OpenID-Integration begonnen, aber sie wird bald kommen.

Hilfreichster Kommentar

Ich denke nur, dass wir wahrscheinlich einen Lauf haben möchten, der die derzeit geöffneten PRs zusammenführt, bevor der Code durch einen Formatierer geleitet wird. Ich bin ganz für pep8/flake8/yapf.

Alle 10 Kommentare

Alle tollen Ideen @JonathanHuot!

Und was denken die Leute über:

  • Aufräumen einiger der alten Äste.
  • Beginnen Sie, die Meilensteine ​​von GitHub zu verwenden, um Releases zu planen (glücklich, einen ersten Lauf auf zB 3.0, 3.1, 4.0 zu machen).
  • Planen, die Unterstützung für Python 2 in einer der Hauptversionen (möglicherweise 4.0) einzustellen.
  • Einführung in Typannotationen (nachdem Python 2 fallen gelassen wurde).
  • Einführung eines Codierungsstils.

@JonathanHuot Ich versuche hier ein wenig Klarheit zu schaffen https://github.com/oauthlib/oauthlib/issues/512

Alles, was ich tun kann, frag einfach.

Einmischen :) Während der Arbeit an einer PR ist mir aufgefallen, dass es keinen Programmierstil gibt, der es manchmal schwer macht, zu folgen. Daran würde ich gerne arbeiten, wenn es euch gut geht. Beginnen Sie vielleicht mit einem Problem, das einen Vorschlag enthält, und nachdem Sie es akzeptiert haben, beginnen Sie mit :nail_care: der Codebasis?

Hallo @MattBlack85 , es ist eine gute Idee, jede Arbeit in dieser Richtung ist willkommen! :-)

_re: Codierungsstil_. Ich habe in Projekten, an denen ich gearbeitet habe, festgestellt, dass ich mit autopep8 und yapf im Grunde Tools den Codierungsstil bereinigen lassen kann, sodass ich mich nicht darum kümmern muss (außer in Fällen, in denen die bereinigte Version weitaus weniger ist) nützlicher, als es ungereinigt zu haben, normalerweise mit klareren Zeilenlängen, die die Längengrenze nur um ein oder zwei Zeichen überschreiten). Ich verwende elpy-mode in Emacs, um das zu vereinfachen, aber ich vermute, dass dies auch in der Befehlszeile und in CI leicht möglich ist.

Ein .editorconfig im Stammverzeichnis des Repos zu haben, war ebenfalls nützlich.

Ich denke nur, dass wir wahrscheinlich einen Lauf haben möchten, der die derzeit geöffneten PRs zusammenführt, bevor der Code durch einen Formatierer geleitet wird. Ich bin ganz für pep8/flake8/yapf.

:+1:

👍

Ich bin ein großer Fan davon, einfach PEP8 zu behalten.

Wenn keine Einwände bestehen, erkläre ich diese Aufgabe für erledigt 🍾

Die neue Community hat einen Patch 2.0.7 und eine Nebenversion 2.1.0 veröffentlicht und wir arbeiten an einer Hauptversion 3.0.0 .

Zögern Sie nicht, mitzumachen und an dieser neuen aufregenden Veröffentlichung teilzunehmen!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

prudnikov picture prudnikov  ·  11Kommentare

JonathanHuot picture JonathanHuot  ·  26Kommentare

potiuk picture potiuk  ·  14Kommentare

ib-lundgren picture ib-lundgren  ·  21Kommentare

thedrow picture thedrow  ·  31Kommentare