Why put ecto configuration in repo.ex

This came up in our project and we weren’t sure why it’s done this way, maybe someone here can shed some light:

Why is it recommended to ‘inject’ ecto database configuration in &Repo.intit/2 ?

eg. hexpm project does so here:

Why wouldn’t they look to use runtime.exs for this?

Most of this code is 3 or even 4 years old, so older than support for runtime.exs.

1 Like

Thanks. But they do have a runtime.exs file: hexpm/runtime.exs at main · hexpm/hexpm · GitHub

So it seems somewhat intentional to leave DB configuration in repo.ex ?

My colleague also pointed out that it seems to be the suggested method in Ecto.Repo docs: Ecto.Repo — Ecto v3.7.1

Would you suggest just using the runtime.exs file for this then?

I think this is mostly up to your preference. Repos and endpoints support passing the config manually so that you can have config in the same file as where it’s consumed. runtime.exs was created to cater to people who want a centralized configuration place which (unlike config.exs) supports runtime config.

I think the community will move towards runtime.exs over time.

1 Like