Oauthlib: Migración a la comunidad de oauthlib
Hola a todos,
Dado que @idan aceptó la migración de la comunidad oauthlib, como equipo, deberíamos enumerar lo que necesitamos para progresar como una verdadera comunidad. Sugiero comenzar con una pequeña lista y, por favor, siéntase libre de participar agregando cualquier sugerencia :-)
Definir / mejorar el proceso de lanzamiento:
- [x]: etiquetado
Números de lanzamientos incorrectos: tenemos 2.0.3 engithub's releases, 2.0.5 en__init__.pyy 2.0.6 enpypi... algo mal seguro - [x]: Publicación
Recomiendo seguir usando Travis para la publicación, sin embargo, podríamos definir la versión directamente usando la variable de entornoTRAVIS_TAG(vea el ejemplo en https://github.com/thomsonreuters/bottle-oauthlib/blob/master/ setup.py en lugar de nuestro valor codificado actual: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py). Además, he visto que @ ib-lundgren es el editor real del paquete pypi, parece inactivo desde hace años, pero no sé si es un problema. - [x]: Documentación
README debe actualizarse con la insignia actualizada para la URL del repositorio de travis-ci.org (el propietario debe habilitarla, AFAIK), y también agregar una insignia para la compilación de la https://readthedocs.org / proyectos / oauthlib / builds / 6483131 /
HECHO EN : https://github.com/oauthlib/oauthlib/pull/520 - [x]: Comunicación
No hay objeción a seguir usando problemas de github y Google+ , sin embargo, parece un poco desactualizado. Además, el canal de IRC #oauthlib está vacío, ~ ¿se pregunta si podríamos crear una sala de Slack si está interesado? ~
CONCLUSIÓN : gitter acudió al rescate. No dude en unirse en https://gitter.im/oauthlib/Lobby
Futuro, hoja de ruta:
- []: ¿Los lavados periódicos de errores podrían ser beneficiosos?
Además, una mesa redonda rápida podría ser genial. Empiezo las introducciones, actualmente estoy trabajando en una implementación de RequestValidator de OAuth2.0 con bottle, y nunca he trabajado con OAuth1.0, ni Django ni Pyramid ni Flask. Sin embargo, estoy tratando de tener un buen conocimiento sobre el RFC involucrado aquí (oauth2, introspect, revocation, jwt ...). Aún no he comenzado la integración de OpenID, pero llegará pronto.
JonathanHuot
Todos 10 comentarios
¡Todas las grandes ideas @JonathanHuot!
Y en que piensa la gente:
- Limpiando algunas de las ramas viejas.
- Comenzar a usar los hitos de GitHub para planificar lanzamientos (feliz de hacer una primera ejecución, por ejemplo, 3.0, 3.1, 4.0).
- Planeando eliminar el soporte para Python 2 en una de las versiones principales (4.0 quizás).
- Introduciendo anotaciones de tipo (después de haber eliminado Python 2).
- Introduciendo un estilo de codificación.
skion
en 1 feb. 2018
@JonathanHuot Estoy intentando aclarar un poco las cosas aquí https://github.com/oauthlib/oauthlib/issues/512
wiliamsouza
en 2 feb. 2018
Cualquier cosa que pueda hacer, solo pídelo.
duaneking
en 14 mar. 2018
repicando :) mientras trabajaba en un PR, noté que no hay un estilo de codificación alrededor, lo que hace que las cosas a veces sean difíciles de seguir. Me gustaría trabajar en eso si estáis bien. Quizás comenzar con un problema que contiene una propuesta y luego ser aceptado, comenzando con: nail_care: ¿el código base?
MattBlack85
en 4 abr. 2018
Hola @ MattBlack85 , es una buena idea, ¡cualquier trabajo en esta dirección es bienvenido! :-)
JonathanHuot
en 4 abr. 2018
_re: estilo de codificación_. He encontrado en proyectos en los que he trabajado que al usar autopep8 y yapf, básicamente puedo dejar que las herramientas limpien el estilo de codificación para no tener que preocuparme por eso (excepto en los casos en que la versión limpia es mucho menor útil que tenerlo sin limpiar, generalmente relacionado con longitudes de línea que serían más claras y solo excederían el límite de longitud por uno o dos caracteres). Utilizo elpy-mode en Emacs para hacerlo más fácil, pero sospecho que podría hacerse fácilmente en la línea de comandos y también en CI.
Tener un .editorconfig en la raíz del repositorio también ha sido útil.
ViktorHaag
en 4 abr. 2018
Solo pienso que probablemente queremos tener una ejecución fusionando los PR actualmente abiertos antes de pasar el código a través de un formateador. Estoy a favor de pep8 / flake8 / yapf.
skion
en 4 abr. 2018
: +1:
MattBlack85
en 5 abr. 2018
👍
Soy un gran fanático de mantener las cosas PEP8.
duaneking
en 12 abr. 2018
Si no hay objeciones, declaro que esta tarea está terminada 🍾
La nueva comunidad ha lanzado un parche 2.0.7 y una versión menor 2.1.0 y estamos trabajando para lograr una versión principal
¡No dudes en contribuir y participar en este nuevo y emocionante lanzamiento!
JonathanHuot
en 23 may. 2018
Temas relacionados
JonathanHuot
·
33Comentarios
prudnikov
·
11Comentarios
ryarnyah
·
3Comentarios
polamayster
·
19Comentarios
ViktorHaag
·
11Comentarios
Comentario más útil
Solo pienso que probablemente queremos tener una ejecución fusionando los PR actualmente abiertos antes de pasar el código a través de un formateador. Estoy a favor de pep8 / flake8 / yapf.