Integrating Our OTP Dependencies into Phoenix—Continued

Using external path dependencies

Suppose we want to work with an external dependency but want the convenience of keeping everything in the same repository. In that case, we can take the same approach we did with persistence and use a poncho-style dependency. Poncho dependencies have an ever-so-slight coupling to their parent projects called an organizational coupling.

Benefits

The benefits of this are development independence with reduced ceremony:

• We’ll be able to evolve interfaces side by side.

• Since all of our dependencies are in the same repository, we’ll be able to keep them in sync better.

Drawbacks

There’s also a downside to path dependencies concerning tooling:

• There’s no automated way to build and test an entire project, dependencies and all.

• If tooling becomes a burden, we can go with an umbrella dependency.

Creating an umbrella project

Let’s make an umbrella project called umbrella_app using the following command:

mix new umbrella_app --umbrella

Let’s take a look at the mix.exs file:

Using umbrella projects

Like poncho projects, umbrella mix projects integrate dependencies in a single repository. Umbrella projects also have another benefit, in that they let developers work on each project independently and do selected tasks project-wide. For example, by using umbrellas, we can choose to run tests for all projects with a single command or switch into a single project and run only those tests.