More like “didn’t particularly pay attention to”. You can find folks who’ll decry the use of ANYTHING - even if statements! - and I wasted waaaaaaay too much time arguing with that sort in Rails-land.

I’ve seen an umbrella solve OP’s specific problem very efficiently - the system was one that coordinated delivery companies (+ drivers) and stores. The key problem the umbrella solved was keeping UIs for different audiences entirely separated; apps were roughly like:

• core: giant ball of DB schemas + business logic
• store_web: UI for stores to use to submit & track delivery requests
• driver_web: UI for drivers to use when making deliveries. Mobile-first, designed to tolerate drivers losing network connectivity intermittenttly
• dispatcher_web: UI for the dispatchers to manage their driver’s work and check status

We didn’t do anything fancy for deployment like splitting subparts (for instance, deploying core + store_web separately) but the built-in boundary checking means we could.

This setup really showed its benefit when Bigco asked us for a new interface that would let Bigco management admin all of their stores. It found a straightforward home as a new bigco_admin_web, with a separate asset pipeline so BigCo could have their logo plastered on everything.

Another nice momement was when we needed to add SAML as a login option, but only for stores. This involved “splitting” the login form to ask for email first, and then either prompt for password or redirect to the IdP. Since each audience has its own _web, it was straightforward to modify only the one for stores.

None of these are strictly “only umbrella could do this”; a team with sufficient organization and discipline could accomplish the same thing all wedged into one Phoenix app, the same way a team like that could make a well-factored Rails monolith. Here in the real world, IMO the umbrella helped us keep things organized despite the hectic schedule of a startup.

I don’t know if you want to introduce complexity from git into your codebase, I personally wouldn’t consider this as a viable option.

Depending on how your projects are organized, I would recommend to have the shared code separated in a library, but in the same repo (a monorepo that hosts both the projects and the library). In this way you can use the option of local dependency and not worry about maintaining separate variants for the library codebase and version them:

defp deps do
  [
    {:local_dependency, path: "path/to/local_dependency"}
  ]
end

If it’s for a sunday afternoon hackathron then copy/paste will likely just work.

The unit of composition for dependencies is not modules, but it’s (otp) applications. Therefore the tools (like mix) for working with dependencies are built for that model. This is not done for lolz as well, given that has always been the unit of how dependencies are resolved within the beam VM and releases (see e.g. *.app files in _build or start scripts in releases). Each app declares it’s dependencies, so if ecto e.g. depends on decimal the vm makes sure to start decimal before ecto.

E.g. if your shared/file.ex depends on ecto, but your new app doesn’t have ecto (or decimal) around things will just blow up. These kinds of dependencies are not tracked on a per module level.

As you’ve figured out – or by using my suggestion of copy/paste – you can always forego proper dependency tracking if you want to. I however wouldn’t call that a good idea nor something that should be encouraged or be made simpler to do. All the primitives to do that exist and can be used, but you want to actively opt in to the fact that you’re sideloading modules and not depending on a third party (otp) application.