Are you interested in integrating some logging capabilities?
karakanb opened this issue · comments
Thanks for your work on vaku, I have been using it for a while and it has been a great help.
One problem I am having is that it is currently not possible to see what is the current progress and what is vaku actually doing; therefore, I was thinking of integrating some logging capabilities to it with a verbose mode. I have two questions about this:
- would you be willing to merge if I came up with such a PR or is this something you are not interested in adding to vaku?
- if yes, would you have any preference for a logging library?
Wow I'm happy to hear that you use vaku! I agree that logging would be useful and I'd be happy to merge a contribution of yours.
I try not to have too many dependencies, so my first reaction is to just use the builtin fmt.Println or log.Println (depending on if you want timestamps). Of course logs would need to be conditional on a cli/client flag like verbose: true so you might need to modify the default logger output based on configuration. But I would be open to adding another library if you think it would add some beneficial features over the standard library?
I'm thinking:
- logging turned off by default
- pass
verbose: trueto the vaku client (and a--verboseflag in the CLI) to turn on logging - logger output defaults to /dev/null
- Setting
verbose: trueupdates the output to stdout
I'm not sure what the go best practice for verbose logging is though so I'm interested in your thoughts as well. Thank you!
Glad to hear that you are interested in it. Vaku has been very helpful to me over the past couple of weeks, and I think I'll keep using it for the search capabilities it offers.
I agree with you in terms of adding dependencies, but this one is something I am torn between. My need for logging came up because I suspect there is a bug in vaku when I search for recursive paths that contain the parent folder name in one of the child folders as well, like burak/burak-sth/secret, and vaku falls into some sort of infinte loop there. While investigating this, I went with adding fmt.Println all around, but then I noticed this got quite messy quite quickly.
When doing investigations like this, having different levels of logs as well as contextual information would be very helpful. During that process, I needed information about what were the folders that were generated, what was the root path for a generated output path, which folders is the tool traversing currently and what are the found paths before the process ends. I agree it is okay that these are turned off by default, but it'd be valuable to be able to toggle various log levels without building a new binary or treating everything as the same level.
Based on these reasons, I was thinking of integrating Zap into vaku: https://github.com/uber-go/zap
My reasoning here is that:
- It is actively maintained, and an easy to use library.
- It supports different log levels.
- It supports contextual information along with the logs.
- Not that it is relevant much here, but it is also fast, as an added benefit compared to alternatives.
I don't really have a strong opinion here to be honest, and from the maintainer point of view I definitely understand the tendency to avoid libraries, I do the same with my own projects as well. In this case, however, it seems like the trade-off might be in favor of adopting a simple common logging solution rather than to build them again. What do you think?
About the problem above, I haven't managed to understand what exactly is causing it; the instance I am running vaku against is quite large, and I haven't had the chance to try it with a local instance with specific criteria. I suspect there is some problem with the EnsurePrefix where the parent is assumed to be there when the folder is parent-sth-else, since it begins with the parent, whereas it should have been made into parent/parent-sth-else. I am telling this because I haven't managed to get to the bottom of it yet, so I don't have enough information to create an issue, but maybe this'd sparkle some ideas in your mind about where might be the problem, and you would be way faster to identify and fix the issue if that's the case. If not, I'll try to create an issue if I can get to the reproducing it properly, and I'd also try to fix it, but I am not sure if I can yet.
Cheers!
My need for logging came up because I suspect there is a bug in vaku when I search for recursive paths that contain the parent folder name in one of the child folders as well, like burak/burak-sth/secret, and vaku falls into some sort of infinte loop there.
That's an interesting problem! I can't think what would cause it off the top of my head but I'm not surprised to hear you've had issues. There's not an easy way to determine where the vault mount ends and where the vault path begins, so there's some functions that guess for any path and they might be getting called when they're not needed.
Based on these reasons, I was thinking of integrating Zap into vaku: https://github.com/uber-go/zap
Zap sounds good to me 🎉 I'd be happy to review and merge a PR that added a --debug flag and some good log lines. I would probably start with logging in the basic list/read/write/delete functions and then add to the higher level functions where needed.
I'm closing this as it looks like the issue was resolved in #98. Thanks again for finding and fixing the problem!
Debug logging could still be useful. Maybe I'll add in the future if I can find the time.
Hi, I know I am late to the game. One thing I want to mention concerning logging: as vaku "prints" useful stuff to stdout, I would prefer every logging to happen to stderr. This is the default behavior for a lot of programs as well and there would be a clear separation.
Hi @mfriedenhagen thanks for the comment! Could you give me an example of something printed to stdout that you think belongs in stderr? I definitely agree that informational logging should be sent to stderr but I'm not sure what you're referring to in vaku. Thanks!
Hi @lingrino: sorry for the misunderstanding , probably my phrasing was too confusing:
vakucurrently does print the things it should/I would expect tostdoutjust fine.- Should there ever be a sort of logging/verbose mode, I would suggest to always use
stderrfor logging output.
In #91 (comment) you mentioned that logging should go to stdout when verbose is requested :-)
Oh I see! Definitely a miscommunication on my part. When I add logging I'll make sure it goes to stderr. Thanks for catching that.