Many projects never remove it even though they don’t use Logger at all. I myself always clean out all comments and skeleton code as well as :logger as soon as I generate a new project, unless I intend to use it very soon. But I have seen so many open source projects just leave it there, from my friends’ projects to widely adopted packages to even community standard tools.
While normally this is not a problem for “pure” Elixir projects, it can be tricky when Erlang dependencies are involved. E.g. :lager used to play badly together with Logger, though this situation seems to be well resolved now. My actual problem arose because ejabberd works around this issue by dropping :lager in favor of Logger, but we depend on :lager's file backend to ship logs around. I spent a good part of yesterday just to remove :logger from the extra_applications list of all my dependencies - none of them use Logger. (couldn’t find an obvious way to just remove :logger when building release w/ distillery)
It also doesn’t feel quite clean to have unused dependencies just laying around.
I would like to know what’s reason behind having it by default in newly generated projects? Is there some deep technical reasons? Or is it just to prevent people mistakenly require Logger without starting it up first?
If there’s a better way to solve my case I would like to know as well.
Thanks ahead!
4 Likes
In Distillery’s case, it used to use Logger, but later shifted to using its own implementation for shell output - it was just never removed from the applications list.
In general I suspect it is there, as you pointed out, to prevent confusion with using Logger when it is not started. This same problem happened all the time with Timex when people would not add it to their applications list, and then call an API which required timezone data (using tzdata which would blow up when not started), so I definitely understand the motivation.
As for projects not playing nicely with Logger, I believe this can be solved with configuration, particularly for use cases like yours by using something like logger_lager_backend. You could also run both Logger and lager side-by-side by configuring Logger not to handle OTP/SASL reports, since I think that is the primary place where conflict is likely to happen. With the new logger module in Erlang’s standard library, I think conflicts between logging libraries will be even less likely, since they will share the same underlying infrastructure, at least as I understand it.
In any case, I’m not advocating for one side or the other, I can see reasons why it is good to include Logger by default, and reasons why maybe it isn’t such a good idea. Ultimately it is still up the library maintainers to “do the right thing”. If a library does depend on Logger, which is common enough, you’ll need to have a strategy to deal with it anyway, so I don’t see changing the default for Elixir projects as really solving the problem you’ve stated.
3 Likes
Requiring the programmers to include an app in the extra_applications list is not rocket science. Not sure what they get confused about, every project on GitHub that needs you to do that is clearly communicating it in their README as far as I have seen so far. Every language and platform has specifics. We are paid to be good at delivering working code, and knowing your tools is an intrinsic part of that.
However, if there are projects that would make use of Logger if it exists in the dependencies and fall back to something else if it doesn’t… that might introduce WTFs indeed.
I see both sides’ arguments but IMO the minimalistic approach should be the default.
1 Like
