Hey Pedro, I've carried out an informal poll with various people (5-10 developers) "what do you expect a default log level to be?" and the answer was *always* "info". These responses came from developers with backgrounds of Java, Node.js and C/C++. Everyone agreed with the notion that debug type logs should be opt-in, rather than opt-out. Your point about the developer turning it off is exactly what I want to avoid in this case; who wants to include a library only to see logging everywhere and then have to figure out how to turn it off? Not a great experience.
The logging interface thing is moot for the case I'm talking about, I think. I'm talking about logging messages internally in a library that can be used to debug things in user-land on an as-needed basis, not something that requires a full logging setup (that's overkill). The Ruby logger does support what you say and logs everything by default (which I assume is why Elixir does it too). Maybe this is the "other log libraries" you're referencing? Their docs actually state that debug is "low-level information for developers". I find that this is actually misleading; if it's only for developers, why is it on by default for end-users? I'm not necessarily arguing that debug should be replaced as the default; if it's familiar to those coming from Ruby then that's fine (and it's easier for backwards compatibility). However I do think that not adding trace/verbose below debug is a mistake and an opportunity to be familiar for those not coming from Ruby. The overhead to adding a new level is seemingly quite minimal and the use case is totally valid (with no good alternatives that I can find). Thank you! IW On Friday, December 1, 2017 at 9:59:48 AM UTC-8, Pedro Medeiros wrote: > > Hi Isaac, thanks for the long explanation. > > "Debug should not log by default (i.e. the default application log level > should be info). This is very familiar coming from other languages" > I find that affirmation a little strange, but as long as I remember the > logging tools that I've used the default log level is debug. Specially for > a language usage. The default logging should keep on debug level that the > developer should turn off deploying applications. > > I don't see the reason to introduce a log level deeper than debug. The > other log libraries that I use has debug as their lowest level. > > One thing that can be done in your case is accept other log libraries at > your library. once is initialized. I'm working now with ruby-kafka and I > kind like its approach > https://github.com/zendesk/ruby-kafka#producing-messages-from-a-rails-application > > . Making it possible to introduce any logger interface that you want as > long as it implements the interface. > > > 2017-11-30 17:11 GMT-05:00 Isaac Whitfield <[email protected] <javascript:>> > : > >> Hi all! >> >> This is kinda hard to word, so hopefully this is clear. I'm not really >> demanding a change, but if people agree I think it would be good going >> forwards: >> >> Say you're writing an Elixir library (which may or may not have an >> application started), and you have something which might do something worth >> noting. You don't know if it's relevant yet, but if it happens in userland >> (i.e. when someone downloaded your lib from Hex) it would be good to know, >> even just for context. Think of the use case where someone sees weird >> behaviour and you need to look at these types of logs to check it out; but >> they're too noisy to be on by default. The lowest level we have available >> to us is debug, which still appears by default. Nobody wants potentially >> noisy logs by default. >> >> Therefore, I'd like to suggest any of the following (although I'm really >> opening this thread for a generally good solution): >> >> 1. Debug should not log by default (i.e. the default application log >> level should be info). This is very familiar coming from other languages, >> and actually fits the name more (if something logs when you're not >> debugging, it's not a debug log). This is a longer term change as it's >> obviously "breaking". >> 2. Introduce a new log level designed for this use case (perhaps >> "trace"?) which is off by default (due to the default level being debug); >> i.e. a user has to turn it on to see any of the logs (and they're removed >> at compile time otherwise). This one appears to be straightforward to add >> in the 1.x lineage. >> 3. ??? you tell me, I'm not really sure how else to deal with it >> currently. >> >> I'd expect that a lot of readers will jump to the concept of the >> application configuration; but refer to the note that not all libraries >> have an application backing them, and having to add one just for this is a >> pain, along with the inevitable bindings you'll have to add for your >> logging. Add that to the fact that a user has to go out of their way to >> turn them off and it makes it an undesirable solution: "why am I seeing all >> of these logs?!", etc. This wouldn't be an issue with a logging level >> that's hidden by default. >> >> I feel like this is something lacking in the existing Logger, and it >> becomes especially evident when coming from other languages where this is >> straightforward (the "debug" module in Node.js is a good example of what >> I'd like, or any of the Java loggers). I would also note that people >> looking at this issue need to keep the concept of >> libraries/packages/modules in mind; this is not something that's relevant >> in your own projects as you can just change it yourself. >> >> Thanks (as ever) for all feedback! >> IW >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/89b48978-4a74-460a-b9ea-6b4f40d56935%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/89b48978-4a74-460a-b9ea-6b4f40d56935%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Pedro Henrique de Souza Medeiros > ---------------------------------- > Cel: +55 (21) 9914-86898 > Email: [email protected] <javascript:> > > Beautiful is better than ugly, > Explicit is better than implicit, > Simple is better than complex, > Complex is better than complicated. > > The Zen of Python, by Tim Peters > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/18c5f0e3-9fe8-4285-a453-4277bed37369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
