Nested apps in umbrella

Questions / Help
1

Hello everyone, I have a question regarding nested apps in an umbrella. I have a set of growing libs and would like put these libs into its own folder.

Current project structure looks something like this:

\umbrella
  mix.exs
  \core
    mix.exs
  \lib_analytics
    mix.exs
  ...
  \lib_utilities
    mix.exs

core depends on lib_analytics and lib_utilities. In core dependency list, I have {:lib_analytics, in_umbrella: true} and {:lib_utilities, in_umbrella: true}.

What I would like to do:

\umbrella
  mix.exs
  \core
    mix.exs
  \libraries
    \analytics
      mix.exs
    \utilities
      mix.exs

What I have tried:

  1. using apps_path: "apps/{core,libraries/*}" as suggested here. But it didn’t work.
  2. using umbrella within umbrella. I kept getting dependencies have diverged errors.

Any pointers would be greatly appreciated! Thanks!

2 Likes
2

Out of curiosity, why do you need your core app to stand alone? What’s wrong with:

umbrella/
├── mix.exs
└── apps/
    ├── analytics/
    │   └── mix.exs
    ├── core/
    │   └── mix.exs
    └── utilities/
        └── mix.exs

This is generally what I do.

Remember, umbrella apps don’t exist to establish a hierarchy between your applications, libraries, and dependencies; their purpose is to allow you to manage several projects from a single directory, ie: using a single git repo for all of them, or fanning out the invocation of a single mix task across all of them.

From this perspective it never makes sense to nest umbrella applications, since those goals would be accomplished identically if you laid them all out inside a single subdirectory, which is probably what you want in this scenario.

1 Like
3

I just realized that the project structure diagrams in my original post were wrong. What I have now is exactly what you suggested:

umbrella/
├── mix.exs
└── apps/
    ├── core/
    │   └── mix.exs
    ├── ex_messagebird/
    │   └── mix.exs
    ├── ex_true_layer/
    │   └── mix.exs
    ├── lib_analytics/
    │   └── mix.exs
    └── lib_utilities/
        └── mix.exs

My main reason to have a nested umbrella is because I wanna set aside all the third party API clients that I wrote so that things look cleaner.

umbrella/
├── mix.exs
└── apps/
    ├── core/
    │   └── mix.exs
    └── libraries/
         ├── ex_messagebird/
         │   └── mix.exs
          ............a lot more in here...........
         └── ex_true_layer/
              └── mix.exs
    ├── lib_analytics/
    │   └── mix.exs
    └── lib_utilities/
        └── mix.exs

Perhaps I just stick with what I have now. :joy: Sometimes I can’t help but over-complicate things.

2 Likes
4

Well, it’s not possible to have that. But if you still want to separate the projects, you can create another umbrella, like this:

umbrella/

  • apps/
    – core/
    – ex_messagebird/
    – ex_true_layer/

umbrella_libs/

  • apps/
    – analytics/
    – utilities/

And then on your mix.exss, refer to the other umbrella dependencies with the path option.

5

I still just make my other ‘apps’ as just dependencies and have a big main project that pulls it altogether, no umbrella at all, never really understood the need for an umbrella…

2 Likes
6

I feel no need for it too, but it helps with some tasks execution on all apps and these kind of things. Though sometimes it fails badly, and other times umbrellas make strange stuff happen…

Well, thinking a little more here, your suggestion does look like a good idea. I’ll test it when I have some time…

1 Like
7

I find it pretty useful for scaffolding a lot of related systems at once while being able to easily run mix tasks across all of them. Little frictions kill big ambitions. :slight_smile: If I were more conscious of my private github repo usage it’d be killer.

A lot of the time things get split out as prescribed, but it’s nice to streamline that pillars-of-creation stage.

1 Like