pyarweb
pyarweb copied to clipboard
Los warnings de docutils deben estar apagados en producción
En mi opinión, mensajes como este en http://python.org.ar/nosotros/:
<<<<<< Updated upstream
System Message: WARNING/2 (<string> line 2)
Title underline too short.
<<<<<<< Updated upstream
=======
deberían ser considerados problemas graves en producción y su origen arreglado de inmediato; cualquier cambio que genere este tipo de resultados (tanto si involucra contenidos, plantillas, lógica de la aplicación, herramientas o la plataforma entera) debería ser revertido ni bien es detectado y hasta que el problema de fondo quede solucionado. Ningún agregado debería justificar, en mi opinión, regresiones de este tipo.
Independientemente de lo anterior, los warnings de docutils deberían silenciarse en producción, e idealmente ser volcados en un log.
@gilgamezh
@angvp lo que yo entiendo es que eso no es un log de docutils. Que es un mensaje por un conflicto de git.
No se cómo se hace para que waliki no muestre eso.
@mgaitan Alguna idea?
hola muchachos. efectivamente, este caso particular es una mezcla de cosas: un rst que se guardó con conflictos y despues rst se confunde con la sintaxis sucia que queda y se queja.
Por qué un archivo se pudo guardar con conflictos es porque hubo una edición simultanea de la pagina que no se pudo automezclar. En ese caso waliki commitea el archivo "as is" (con conflicto) pero inmediatamente redirige al usuario al editor (ver acá), para que arregle y genere una nueva versión.
Es polémico guardar una versión con conflictos. quizas la actual podria ser una politica configurable y tener otra más simple "ultima edición gana" y chau.
Respecto al nivel de warnings, creo que bastaria con setear el nivel de report_level en settings WALIKI_MARKUPS_SETTINGS
No hace falta redefinir todo el dict, se extiende si la clave no está. entonces, algo asi
WALIKI_MARKUPS_SETTINGS = {'reStructuredText': {
'settings_overrides': {
'report_level': 5,
}
}