hauleth

hauleth

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.

Showing Posts 1 to 4

dimitarvp

dimitarvp

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.

hauleth

hauleth OP

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.

dimitarvp

dimitarvp

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.

hauleth

hauleth OP

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.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
achempion
I’ve been using Emacs as my main code editor for more than a two years. It’s a custom build version although I’ve tried doom emacs and sp...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews