Telliot: Utilice un registro coherente en lugar de printf en todas partes.

Creado en 26 sept. 2020  ·  9Comentarios  ·  Fuente: tellor-io/telliot

El código base tiene printf en muchos lugares, lo que es fácil de comenzar, pero al analizar o filtrar registros, aparecen muchos problemas más adelante con la supervisión y el seguimiento.

un registrador debe inicializarse en el paquete principal y luego pasar a todos los constructores de paquetes.

Este es un paquete de registro muy bueno
github.com/go-kit/kit/log

para ver un ejemplo de cómo implementar, mire los proyectos de thanos o prometheus.

todos los printf-s comentados se pueden reemplazar con registros de depuración para que se muestren solo cuando la depuración está habilitada.
level.Debug(logger).Log("msg", "debug")

¡Importante! Verifique las pautas de codificación del proyecto
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md

good first issue help wanted .high

Todos 9 comentarios

¡Tomaré este hoy!

Una actualización: esto está parcialmente hecho, pero todavía hay pocos lugares con printf y logrus.
TL-DR necesita usar github.com/go-kit/kit/log en todas partes. Debe pasarse como argumento al inicializar los componentes.

Estado del problema: 1. Abierto 2. Iniciado 3. Enviado 4. Listo


__Este número ahora tiene un financiamiento de 0.1 ETH (114.26 USD @ $ 1142.63 / ETH) adjunto como parte del fondo Tellor-io .__

@ krasi-georgiev Me gustaría asumir esto, pero después de leer sus sugerencias sobre Gitcoin y leer el código de Telliot, diría que en lugar de cambiar todos los comentarios fmt.Printf a level.Debug (logger) .Log (... .) debemos decidir en cada situación qué tiene más sentido desde la perspectiva del usuario.
Usaría la depuración de registros cuando la salida debería ser útil para inspeccionar un problema, más desde el punto de vista de un desarrollador, pero las situaciones en las que el usuario espera una salida en la consola, deberían ser del nivel INFO. Como por ejemplo
https://github.com/tellor-io/telliot/blob/master/pkg/ops/disputeOps.go#L249 -L255

    fmt.Printf("Dispute %s (%s):\n", dispute.DisputeId.String(), descString)
    fmt.Printf("    Accused Party: %s\n", reportedAddr.Hex())
    fmt.Printf("    Disputed by: %s\n", reportingMiner.Hex())
    fmt.Printf("    Created on:  %s\n", createdTime.Format("3:04 PM January 02, 2006 MST"))
    fmt.Printf("    Fee: %s TRB\n", util.FormatERC20Balance(uintVars[8]))
    fmt.Printf("    \n")
    fmt.Printf("    Value disputed for requestID %d:\n", dispute.RequestId.Uint64())

Por favor corrígeme si estoy equivocado. ¡Gracias!

sí, muy cierto! También otra regla es que si un registro ocurre una vez al inicio, está bien que sea información, pero si sucede muchas veces en un bucle, a menos que sea extremadamente importante, en la mayoría de los casos, esto es demasiado ruido y debe ser depurado.

@ krasi-georgiev Sí, tiene sentido no abrumar al usuario, pero creo que en situaciones en las que desea analizar los registros con una herramienta, cambiar el comportamiento puede ser confuso ya que esa es la única retroalimentación que tiene para su análisis, pero de todos modos obtendremos el equilibrio adecuado, creo. Voy a hacer algunos cambios aquí y, a medida que aprenda más sobre este proyecto, encontraremos lo que funciona para una buena experiencia de usuario.

Una vez hecho esto, también debería agregar en el mismo PR un poco más de pelusa al archivo MAKE como

go-lint: check-git deps $(GOLANGCI_LINT) $(FAILLINT)
    $(call require_clean_work_tree,'detected not clean master before running lint, previous job changed something?')
    <strong i="6">@echo</strong> ">> verifying modules being imported"
    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...
    <strong i="7">@echo</strong> ">> linting all of the Go files GOGC=${GOGC}"
    @$(GOLANGCI_LINT) run
    <strong i="8">@echo</strong> ">> ensuring Copyright headers"
    <strong i="9">@go</strong> run ./scripts/copyright
    $(call require_clean_work_tree,'detected files without copyright, run make lint and commit changes')

las 2 líneas etra son:

    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...

Esto hará cumplir que no hay declaraciones impresas en ningún lugar y también que pkg/errors se usa en todas partes

Estado del problema: 1. Abierto 2. Iniciado 3. Enviado 4. Listo


__Se ha iniciado el trabajo__.

Cada uno de estos usuarios afirmó que puede completar el trabajo en 265 años, 6 meses a partir de ahora.
Revise sus planes de acción a continuación:

1) g33kidd ha solicitado comenzar a trabajar _ (solo para financiadores: aprobar trabajador | rechazar trabajador ) _.

Intentaré esto, parecía algo interesante de hacer.
2) voanhcung ha solicitado comenzar a trabajar _ (solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Ok [email protected] .......................
3) therocketcat ha sido aprobado para comenzar a trabajar.

Miré la base del código y los proyectos de ejemplo mencionados anteriormente que mencionaste.

De los ejemplos, he recopilado que si las funciones que usan printf no tienen un constructor, entonces el registrador debe inyectarse dependencia en la función en sí. Si este no es el caso, me gustaría aclararlo.

Y en el paquete principal (telliot / cmd / telliot / main.go) se configurarán utilizando la función SetupLogger de util y se pasarán al constructor o se inyectarán directamente en la función (como primer parámetro).

También mirando el código base no puedo encontrar ningún printfs comentado, así que supongo que te refieres a printfs en general.

Abierto para discutir esto más a fondo si he entendido mal la tarea RocketCat # 3507
4) mendesfabio ha solicitado comenzar a trabajar _ (solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Acabo de revisar el repositorio y parece que se reemplazaron algunos printf-s (y me ayudó a entender cómo hacerlo). Todavía tenemos 10 archivos con printf-s y lo cambiaré.
5) rodrigoadriandiaz ha solicitado comenzar a trabajar _ (solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Podría hacer esto, reemplazando todas las llamadas a printf para una implementación del paquete de registro mencionado anteriormente, podría comenzar a trabajar en esto mañana
6) raulcorreia7 ha solicitado comenzar a trabajar _ (solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Hola,
Esto sería una obviedad,
DM me.
7) coder4520 ha solicitado comenzar a trabajar _ (solo para financiadores: aprobar trabajador | rechazar trabajador ) _.

Supongo que este sería un buen primer proyecto para empezar.
8) adiprerepa ha solicitado comenzar a trabajar _ (solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Esto sería muy fácil: simplemente busque y reemplace printf por el registro y luego verifique dos veces.
9) xf3rno ha solicitado comenzar a trabajar _ (Solo financiadores: aprobar trabajador | rechazar trabajador ) _.

Realizaría la tarea solicitada; reemplace todos los registros actuales con la biblioteca de registros de golang de Google (bastante liviana: https://github.com/google/logger) y alcance cada mensaje según el contexto (depuración, advertencia, etc.).

Obtenga más información en la página de detalles del problema de Gitcoin .

Estado del problema: 1. Abierto 2. Iniciado 3. Enviado 4. Listo


__Trabajo por 0.1 ETH (167.47 USD @ $ 1674.72 / ETH) ha sido enviado por__:


¿Fue útil esta página
0 / 5 - 0 calificaciones