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.

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.