enhancing "mix xref deprecated"?

[Rich Morin]

Reading José's recent blog

What’s new in Elixir – Apr/19
http://blog.plataformatec.com.br/2019/04/whats-new-in-elixir-apr-19

made me think about a possible enhancement to "mix xref deprecated".
Specifically, I'd like it to warn me about deprecated practices in
file system organization and use. For example, José says that

> The first change is that we will no longer generate config/config.exs
> for projects generated with mix new. Relying on configuration is
> undesired for most libraries and the generated config files pushed
> library authors in the wrong direction. Furthermore, mix new
> --umbrella will no longer generate a configuration for each child app;
> instead, all configuration should be declared in the umbrella root.
> That’s how it has always behaved, we are now making it explicit.


Mix could help us pull existing projects into compliance by telling us
about it when they contain deprecated file usage. To be clear, I don't
really care if the relevant command string is "mix xref deprecated"; I
just want a quick, informative report on things I should address.

-r

[José Valim]

Do you have another example of where this functionality would be used? Because config/config.exs is not really deprecated, we just won’t generate it by default.

--

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

[Rich Morin]

> On Apr 30, 2019, at 23:29, José Valim <jose....@plataformatec.com.br> wrote:
>
> Do you have another example of where this functionality would be used? Because config/config.exs is not really deprecated, we just won’t generate it by default.

Ah, but the _reason_ you're making this change is that you don't consider it to be
a Best Practice. So, even if it's "not really deprecated", you don't want to put
programmers into the position of doing it unintentionally. I agree with this, but
it doesn't solve the problem of existing code. And code smells accumulate...

I haven't been tracking changes closely, so I can't give you any other specifics.
And really, that is kind of my point. As a programmer using the Elixir tooling,
I shouldn't _have_ to track changes closely: Mix should be able to tell me about
questionable practices in my code base. I can then decide what, if anything, I
want to do about them.

By way of analogy, I disagree with the formatter's handling of inline white space.
However, unlike Golang, Elixir allows me to disagree. And, if I am curious about
what things the formatter would change, I can simply run it on a copy of my source
tree and do a recursive diff(1). So, I get information, but I'm not compelled to
do anything I don't want to. My proposed enhancement would be in this same spirit.

-r

[José Valim]

Ah, but the _reason_ you're making this change is that you don't consider it to be
a Best Practice.

No, that's not the reason. config/config.exs is totally fine in certain use cases. Furthermore,

config/config.exs is totally valid for *all applications*. The check you are asking would

be a false positive for the huge majority of Elixir projects out there.

Here is a better example. Imagine that in all applications generated by mix.new, we had

a macro as an example:

defmodule Hello do

  defmacro world, do: :ok

end

 

Is that code wrong? Definitely not. But we can decide to not start a new app with

a macro as an example (as there are better options).

 

I haven't been tracking changes closely, so I can't give you any other specifics.
And really, that is kind of my point.  As a programmer using the Elixir tooling,
I shouldn't _have_ to track changes closely:

I understand your point. But please understand that the lack of other examples

do not help move this discussion forward. I personally cannot think of any use

case for the proposed warning/check, so unless someone presents a counter-

argument or another example, there isn't anything to change.

[Rich Morin]

Points taken. Since I don't have any other uses cases to offer, perhaps this
is a non-issue for the moment. FWIW, this reminds me of the situation with
lint (https://en.wikipedia.org/wiki/Lint_(software)) and similar tools. They
can be useful, but only if they don't generate too many diagnostics.

-r