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.
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
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.
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.