Move some configurations in the generated files

phoenix
generators
#1

Currently Phoenix generates configuration for Ecto in the config/config.exs (I mean option :ecto_repos). Why there? Instead of polluting config.exs (and by extension sys.config) with needless configuration options I believe it would be better to use application env instead. For these unaware of this feature, you can specify “global” configuration within application/0 callback in Mix.Project, ex.:

defmodule MyProject.Mixfile do
  use Mix.Project

  # …

  def application do
    [
      mod: {MyProject.Application, []},
      extra_applications: [:logger],
      env: [
        ecto_repos: [MyProject.Repo]
      ]
    ]
  end

  # …
end

This will keep only runtime configuration (this option is used almost exclusively in development and testing) in config/config.exs and will not pollute sys.config in the result.

1 Like

#2

I would love it if we could do that for every dependency!

We can also have mini functions like this:

def config(:ecto_sql), do: ...
def config(:codepagex), do: ...
def config(:phoenix), do: ...

It would be damn beautiful.

0 Likes

#3

This would bring no improvement over config/config.exs as such options would still need to land in the sys.config (as you should not edit other applications app.src files). What would be more helpful would be allowing to define separate config file that would be loaded only at compile time. Alternatively provide something to define “compile time options” so instead of setting compile time options in config/config.exs we could configure it somewhere else and access it for example via Module.compile_env/1-3 or similar.

0 Likes

#4

I’m not entirely sure what’s your pet peeve against more config landing in sys.config. I mostly agree with it but I don’t see it as fatal.

My main point is: have dedicated places for config.

For newcomers to your project (or to Elixir itself) it is mighty confusing to have to discover 7-10 source code files containing configuration which can by anywhere in the tree.

Config in a dedicated directory and nowhere else would be a strong quality of life improvement.

Keeping things simple is a disappearing ancient art, it seems.

0 Likes

#5

The reason is that after some time I come to liking sys.config and in my deployments I could use this directly instead of using additional tools like config providers. But it become troublesome when this file grows larger and larger for no apparent reason.

What I mean is exactly that - have one config file, but keep only runtime configuration there. How often you edit :ecto_repos? This is configuration option needed only for mix ecto.* tasks and is used by anything else, so why the hell it is in config/config.exs at all? This option do not configure my application in any way, only tooling, and to be exact - mostly development tooling, as often you do not have mix in production.

And that is what I am trying to achieve there - hide unneeded entries from users and keep configuration files as simple and short as possible, do not bloat them with compile time and tooling configuration that has nothing to do with my application behaviour.

1 Like