Oauthlib: Migration to oauthlib community
Hi everyone,
Since @idan accepted the oauthlib community migration, as a team, we should list what do we need to progress as a true community. I suggest to start with a small list, and please anyone, feel free to participate by adding any suggestions :-)
Define/Improve release process:
- [x] : Tagging
Wrong releases numbers: we have 2.0.3 ongithub's releases, 2.0.5 in__init__.pyand 2.0.6 onpypi...something wrong for sure - [x] : Publishing
I'd recommand to continue to use Travis for publishing, however we could define version directly by using environment variableTRAVIS_TAG(see example at https://github.com/thomsonreuters/bottle-oauthlib/blob/master/setup.py instead of our current hard-coded value: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py ). Also, I've seen @ib-lundgren is the actual publisher of the pypi package, he looks inactive since years, but dunno if it's an issue. - [x] : Documentation
README needs to be updated with the updated badge for travis-ci.org repository URL (owner must enable it, AFAIK), and also add a badge for the documentation build, cuz it's failing since long time: https://readthedocs.org/projects/oauthlib/builds/6483131/
DONE IN: https://github.com/oauthlib/oauthlib/pull/520 - [x] : Communication
No objection to continue using github issues and Google+, however it seems a bit outdated. Also, the #oauthlib IRC channel is empty, ~wondering if we could create a Slack room if interested?~
CONCLUSION: gitter came to the rescue. Feel free to join at https://gitter.im/oauthlib/Lobby
Future, roadmap:
- [ ] : Do periodic bugs washes could be beneficial
Also, a quick round table could be great. I start the introductions, I'm currently working on a OAuth2.0 RequestValidator implementation with bottle, and I've never worked with OAuth1.0, nor Django nor Pyramid nor Flask. However, I'm trying to have a good knowledge around the RFC involved here (oauth2, introspect, revocation, jwt...). I have not started yet the OpenID integration, but it will come soon.
JonathanHuot
All 10 comments
All great ideas @JonathanHuot!
And what do people think about:
- Cleaning up some of the old branches.
- Starting to use GitHub's milestones to plan releases (happy to make a first run on e.g. 3.0, 3.1, 4.0).
- Planning to drop support for Python 2 in one of the major releases (4.0 perhaps).
- Introducing type annotations (after having dropped Python 2).
- Introducing a coding style.
skion
on 1 Feb 2018
@JonathanHuot I'm trying clear things a little bit here https://github.com/oauthlib/oauthlib/issues/512
wiliamsouza
on 2 Feb 2018
Anything I can do just ask.
duaneking
on 14 Mar 2018
chiming in :) while working on a PR I noticed there is no coding style around which makes things sometimes hard to follow. I'd like to work on that if you guys are ok. Maybe starting with a issue containing a proposal and after that being accepted, starting to :nail_care: the codebase?
MattBlack85
on 4 Apr 2018
Hi @MattBlack85, it's a good idea, any work in this direction is welcomed ! :-)
JonathanHuot
on 4 Apr 2018
_re: coding style_. I've found in projects I've worked on that by using autopep8 and yapf, I can basically let tooling clean up the coding style so I don't have to worry about it (except in cases where the cleaned up version is far less useful than having it un-cleaned-up, usually to do with line-lengths that would be clearer and only exceed the length boundary by a character or two). I use elpy-mode in Emacs to make that easy, but I suspect it could easily be done in command-line, and CI, as well.
Having an .editorconfig in the root of the repo has also been useful.
ViktorHaag
on 4 Apr 2018
Just thinking we probably want to have a run merging the currently open PRs before passing the code through a formatter. I'm all for pep8/flake8/yapf.
skion
on 4 Apr 2018
:+1:
MattBlack85
on 5 Apr 2018
👍
I'm a big fan of just keeping things PEP8.
duaneking
on 12 Apr 2018
Related issues
JonathanHuot
·
15Comments
ViktorHaag
·
11Comments
ggiill
·
7Comments
JonathanHuot
·
33Comments
potiuk
·
14Comments
Most helpful comment
Just thinking we probably want to have a run merging the currently open PRs before passing the code through a formatter. I'm all for pep8/flake8/yapf.