A base de código tem printf em muitos lugares, o que é fácil de começar, mas ao analisar ou filtrar logs, ele traz muitos problemas posteriormente com monitoramento e rastreamento.
um logger deve ser inicializado no pacote principal e então passado para todos os construtores de pacotes.
Este é um pacote de registro muito bom
github.com/go-kit/kit/log
para um exemplo de como implementar veja os projetos thanos ou prometheus.
todos os printf-s comentados podem ser substituídos por logs de depuração para que sejam exibidos apenas quando a depuração estiver habilitada.
level.Debug(logger).Log("msg", "debug")
Importante! Verifique as diretrizes de codificação do projeto
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md
Vou levar este hoje!
Uma atualização: isso está parcialmente feito, mas ainda existem poucos lugares com printf e logrus.
TL-DR precisa usar github.com/go-kit/kit/log em qualquer lugar. Ele precisa ser passado como um argumento ao inicializar os componentes.
Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__Esta emissão agora tem um financiamento de 0,1 ETH (114,26 USD @ $ 1142,63 / ETH) anexado a ela como parte do fundo Tellor-io .__
@ krasi-georgiev Eu gostaria de abordar isso, mas depois de ler suas sugestões sobre Gitcoin e ler o código Telliot, eu diria que em vez de alterar todos os comentários de fmt.Printf para level.Debug (logger) .Log (... .) devemos decidir em cada situação o que faz mais sentido do ponto de vista do usuário.
Eu usaria o log debug quando a saída fosse útil para inspecionar um problema, mais do ponto de vista do desenvolvedor, mas as situações em que o usuário espera uma saída para o console devem ser de nível INFO. Como por exemplo
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 me corrija se eu estiver errado. Obrigado!
sim, é verdade! Outra regra também é que um log acontece uma vez na inicialização, não há problema em ser info, mas se acontecer muitas vezes em um loop, a menos que seja extremamente importante na maioria dos casos, isso é muito ruído e deve ser depurado.
@ krasi-georgiev Sim, faz sentido não sobrecarregar o usuário, mas acho que em situações em que você deseja analisar os registros com uma ferramenta, mudar o comportamento pode ser confuso, pois esse é o único feedback que você tem para a sua análise, mas de qualquer maneira vamos conseguir o equilíbrio certo, eu acho. Vou fazer algumas mudanças aqui e à medida que aprendo mais sobre este projeto, descobriremos o que funciona para uma boa experiência do usuário.
uma vez feito isso, também deve adicionar no mesmo PR um pouco mais de linting ao makefile, 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')
as 2 linhas etra são:
@$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
@$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...
Isso fará com que não haja instruções de impressão em qualquer lugar e também que pkg/errors
seja usado em qualquer lugar
Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__Trabalho foi iniciado__.
Cada um desses usuários afirmou que pode concluir o trabalho em 265 anos, daqui a 6 meses.
Reveja os seus planos de ação abaixo:
1) g33kidd se inscreveu para iniciar o trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Vou tentar fazer isso, parecia uma coisa interessante a fazer.
2) voanhcung candidatou-se para iniciar o trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Ok [email protected] .......................
3) therocketcat foi aprovado para começar a trabalhar.
Eu olhei a base de código e os projetos de exemplo mencionados anteriormente que você mencionou.
A partir dos exemplos, concluí que, se as funções que usam printf não têm um construtor, o logger deve ser a dependência injetada na própria função. Se este não for o caso, gostaria de esclarecimentos.
E no pacote principal (telliot / cmd / telliot / main.go) eles serão configurados usando a função SetupLogger do util e passados para o construtor ou injetados diretamente na função (como primeiro parâmetro).
Também olhando para a base de código, não consigo encontrar nenhum printfs comentado, então estou supondo que você quer dizer printfs em geral?
Abra para discutir isso melhor se eu entendi mal a tarefa RocketCat # 3507
4) mendesfabio candidatou-se para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Acabei de verificar o repo e parece que alguns printf-s foram substituídos (e isso me ajudou a entender como fazer isso). Ainda temos 10 arquivos com printf-s e vou mudar isso.
5) rodrigoadriandiaz se candidatou para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
eu poderia fazer isso, substituindo todas as chamadas para printf por uma implementação do pacote de registro mencionado acima, poderia começar a trabalhar nisso amanhã
6) raulcorreia7 candidatou-se para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Oi,
Isso seria um acéfalo,
DM mim.
7) coder4520 solicitou o início do trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Eu acho que este seria realmente um bom primeiro projeto para começar.
8) adiprerepa solicitou o início do trabalho _ (Financiadores apenas: aprovar trabalhador | rejeitar trabalhador ) _.
Isso seria muito fácil - basta localizar e substituir printf no registro e, em seguida, verificar novamente.
9) xf3rno solicitou o início do trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Eu realizaria a tarefa solicitada; substitua todo o registro atual pela biblioteca golang logger do Google (bastante leve: https://github.com/google/logger) e defina o escopo de cada mensagem de acordo com o contexto (depuração, aviso, etc.).
Saiba mais na página Detalhes do problema do Gitcoin .
Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__Trabalho para 0,1 ETH (167,47 USD @ $ 1674,72 / ETH) foi enviado por ___: