[erlang-questions] Deprecation warnings: OTP20 and OTP21 compatible code

[José Valim]

FWIW, Mix also disables warnings as errors for both Erlang (Rebar) and
Elixir (Mix) dependencies, for exactly the same reasons outlined by Loïc.



*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

On Wed, Jun 6, 2018 at 1:38 PM, Loïc Hoguin <essen@REDACTED> wrote:

> On 06/06/2018 01:18 PM, Fred Hebert wrote:
>
>> On 06/06, Loïc Hoguin wrote:
>>
>>> It's worth noting that you did not have an issue with Cowboy, Ranch and
>>> friends. That's because the default policy in Erlang.mk is to NOT use
>>> warnings_as_errors for dependencies (and as a result this option is not
>>> included in the generated rebar.config).
>>>
>>> This saves a lot of headaches. erlang:get_stacktrace/0 is notable in how
>>> widely used it is but issues with warnings_as_error have always existed for
>>> as long as I've been doing Erlang. Tools should really have a saner default
>>> policy for this. The build shouldn't break for your users just because a
>>> new warning was introduced.
>>>
>>>
>> Rebar3 leaves the warnings that libs put for themselves there.
>>
>> There's a PR currently going about adding a 'del' override, which would
>> let someone remove the option by specifying:
>>
>> {overrides, [
>>     {del, [
>>         {erl_opts, [warning_as_errors]}
>>     ]}
>> ]}
>>
>> and would let you instantly remove the option from all dependencies
>> rather than having to go through the override pattern Jesper has shown here.
>>
>> If/Once merged, it would help address the problem. I'm a bit hesitant to
>> go and disable some options _by default_ when library authors have set them
>> there for a reason.
>>
>
> They have a reason of course: this option is great during development.
> Everyone should use it.
>
> Building as a dependency is a different context though and having your
> dependencies break every time there's a new OTP version is not the best
> user experience. I suppose Rebar3 has a way to have stricter compilation
> profiles for use during development, but I haven't seen much use of that.
> So it falls down to each dependency's user to fix those issues, and that's
> a problem.
>
> It being a default may or may not be a good idea, I don't know. All I do
> know is that nobody complained and nobody asked for an option to disable
> that behavior so I think it's good enough for now. It's one less problem to
> worry about. Rebar has more users and with a different mindset so the same
> may not apply.
>
> --
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180606/8efcf7cc/attachment.htm>