Use the Config module instead of Mix.Config is deprecated

[joustava]

Gets rid of: warning: use Mix.Config is deprecated. Use the Config module instead config/config.exs:3

[UncleGrumpy]

Thank you! This has been nagging at us for a while. I meant to investigate the fix, but I spend most of my time working in Erlang so I keep forgetting about this.

[joustava]

@UncleGrumpy I missed a little detail in migrating to the use of the Config module. Although the deprecated use of Mix.env() is commented out in config.exs, I thought it is good measure to also migrate it to the use of config_env(). Sorry for the extra overhead.

[petermm]

Let's back out mix.lock here - I also believe this change bumps the minimum elixir version in mix.exs?

[joustava]

Let's back out mix.lock here ...

It can be backed out if wished. However, It is not listed in .gitignore and it seems to be standard to include mix.lock? If there is a reason not to include of which I am ignorant it might be a good idea also to list it in .gitignore? Also: #39

... I also believe this change bumps the minimum elixir version in mix.exs?

Yes, it should be 1.9, I believe there is the first deprecation warning.

[petermm]

Backing out mix.lock here is only to avoid conflict with how it's part of #41 - in a different shape.

[UncleGrumpy]

@UncleGrumpy I missed a little detail in migrating to the use of the Config module. Although the deprecated use of Mix.env() is commented out in config.exs, I thought it is good measure to also migrate it to the use of config_env().

Sorry for the extra overhead.

This is one thing I definitely need to defer to @bettio and @petermm as they are far more familiar with Elixir and it's tooling than I am. Don't let the fact that I contributed a few of the tasks fool you, I an am a neophyte when I comes to Elixir. ;-)

[joustava]

This is one thing I definitely need to defer to @bettio and @petermm as they are far more familiar with Elixir and it's tooling than I am. Don't let the fact that I contributed a few of the tasks fool you, I an am a neophyte when I comes to Elixir. ;-)

Basically boils down to this afaik.

[UncleGrumpy]

Thanks for the links... I believe this section is speaking directly to us, and the situation here:

"The only places where you may access functions from the Mix module are the mix.exs file and inside custom Mix tasks, which are always within the Mix.Tasks namespace."

This seems to imply that using Mix.Config is still valid in this case.

[joustava]

This seems to imply that using Mix.Config is still valid in this case.

Mix.Config module shouldn't be used as it is replaced by Config module (this is the reason of the warning) and this was used in ./config/config.exs which is neither in mix.exs or within a Mix.Task namespace.

[UncleGrumpy]

Mix.Config module shouldn't be used as it is replaced by Config module (this is the reason of the warning) and this was used in ./config/config.exs which is neither in mix.exs or within a Mix.Task namespace.

Thanks for the clarification! This is why I said I should defer to @bettio and @petermm on this. lol.

[petermm]

I'm more inclined towards deleting file(and folder) or commenting out import (Mix.)Config line, effectively leaving the entire file commented out - as it not used, and probably shall never be used:

https://hexdocs.pm/elixir/1.18.2/Config.html

If you are writing a library to be used by other developers, it is generally recommended to avoid the application environment, as the application environment is effectively a global storage. Also note that the config/config.exs of a library is not evaluated when the library is used as a dependency, as configuration is always meant to configure the current project. For more information, see "Using application configuration for libraries".

[bettio]

it has been superseeded from #49.