[Proposal/Feedback] Changes to Logger to introduce off-by-default semantics
126 views
Skip to first unread message
Isaac Whitfield
Nov 30, 2017, 5:11:48âŻPM11/30/17
to elixir-lang-core
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
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
Pedro Medeiros
Dec 1, 2017, 12:59:48âŻPM12/1/17
to elixir-l...@googlegroups.com
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.
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/89b48978-4a74-460a-b9ea-6b4f40d56935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Pedro Henrique de Souza Medeiros
----------------------------------
Cel: +55 (21) 9914-86898
Email: pedr...@gmail.com
----------------------------------
Cel: +55 (21) 9914-86898
Email: pedr...@gmail.com
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
Isaac Whitfield
Dec 1, 2017, 8:18:02âŻPM12/1/17
to elixir-lang-core
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
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 <i...@whitfin.io>:
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/89b48978-4a74-460a-b9ea-6b4f40d56935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Allen Madsen
Dec 1, 2017, 11:05:42âŻPM12/1/17
to elixir-l...@googlegroups.com
I could be misunderstanding you, but you seem to be implying that every library you use has to be configured not to log at the debug level. That's not actually the case. If you put `config :logger, level: :info` in your config.exs, your code and every dependency you have will log at the info level. It doesn't matter if a dependency exposes an application.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/18c5f0e3-9fe8-4285-a453-4277bed37369%40googlegroups.com.
Isaac Whitfield
Dec 2, 2017, 4:21:34âŻAM12/2/17
to elixir-lang-core
Yes, it appears you are misunderstanding.
I am aware that you can (and can only) disable the log level for everything at once. Making all your logs run at :info because of a library logging a lot at debug is not a good solution.
I am aware that you can (and can only) disable the log level for everything at once. Making all your logs run at :info because of a library logging a lot at debug is not a good solution.
Isaac Whitfield
Dec 3, 2017, 12:35:00âŻAM12/3/17
to elixir-lang-core
Based on some feedback on Slack, here's what I believe should be the solution (note that it's backwards compatible so it's fine for the 1.x lineage).
1. Introduce a new log level which is off by default, e.g. :trace. This allows the default to stay at :debug, so no change there.
2. Add a new option to the Logger configuration, :applications, which allows setting of log level per-application. This would allow overriding the default log level for a specific application only, so you can tailor manually.
This allows a library developer to just say "hey, can you turn on debug logs for LibX?" to get logs, but without being noisy all the time. It also keeps compatibility with the behaviour that people know and are used to today. I think this is a good solution for everyone?
Anyone have any thoughts on this? Appreciate feedback.
IW
1. Introduce a new log level which is off by default, e.g. :trace. This allows the default to stay at :debug, so no change there.
2. Add a new option to the Logger configuration, :applications, which allows setting of log level per-application. This would allow overriding the default log level for a specific application only, so you can tailor manually.
This allows a library developer to just say "hey, can you turn on debug logs for LibX?" to get logs, but without being noisy all the time. It also keeps compatibility with the behaviour that people know and are used to today. I think this is a good solution for everyone?
Anyone have any thoughts on this? Appreciate feedback.
IW
Reply all
Reply to author
Forward
0 new messages