Clarify project settings in child projects of umbrella

Questions / Help
, ,
1

Hello,

I believe all child application mix.exs files I have seen have the following settings:

build_path: "../../_build",
config_path: "../../config/config.exs",
deps_path: "../../deps",
lockfile: "../../mix.lock",

If all child projects are configured like this, why do we need these configuration parameters at all ? They could be assumed by the tools that build umbrella projects and their children.

These parameters only make sense to exist if there are umbrella projects’ use cases where they need to be configured in different ways. What are those (rare) use cases?

Thanks

2

Afaik when running commands from within those child applications mix is blissfully unaware it‘s part of an umbrella structure.

Edit
To describe it differently: Only because of those lines mix knows it’s supposed to use those top level files of the umbrella structure.

2 Likes
3

So, for some aspects Mix knows about umbrella projects (e.g., mix new ... --umbrella), but when run inside child apps it ignores the fact these belong to an umbrella project, hence setting the parameters like above serves as a workaround for this fact. That’s what I understood.

Regarding the second question, in what use cases it makes sense to set these parameters in child configurations to different values?

4

It doesn’t make sense to have those values be different in an umbrella, but as mentioned not having them is a problem. Those settings are available in mix because people might want to create a custom setup e.g. when integrating with tooling outside of mix, which requires those files to be in non default locations.
Umbrellas simply use this flexibility, which is already part of mix, for its usecase of handling many mix projects as a coherent unit.

5

I see a custom setup which is to have each app its own config/config.exs, thus making it possible to have Mix compile and launch a child app independently of others, which can make the development workflow faster. Then, the config/config.exs in the umbrella would import each child config.exs. I have tested this setup and it seems to work very well.

6

The drawback (and the reason for 1.9 to removed child level config for umbrellas) is that it’s harder to detect conflicting configuration that way.

7

Yep, we must be conscious of the tradeoffs.

Perhaps some conflicts can be resolved in the umbrella’s config.exs after importing the children’s config.exs