[erlang-questions] how do you build your releases with/without rebar?

[Garrett Smith]

On Wed, Apr 16, 2014 at 2:03 PM, Yuri Lukyanov <snaky@REDACTED> wrote:
>
> Well, I can add our story.

Thanks for this!

> In the beginning, we had a single repository for everything. And even
> without apps dir. It was a single monster with everything inside the
> src dir. At some point, it became obvious that it couldn't go on like
> this and we started separating the code into apps. 'apps' directory
> looked like a good fit.
>
> Then we came across Riak and its sources. The way they organised their
> code seemed so gorgeous. A tiny repository for each application! Super
> easy to think of as a separate unit of your system. Different teams
> work on different repositories. Independent testing. Ability to open
> certain parts of your project to the community. Superb!
>
> And we started a 'big move' to that world. At the beginning,
> everything was smooth. Later, we even created a project template that
> uses that every-app-is-a-repo structure
> (https://github.com/EchoTeam/rebar-templates).
>
> But what we ended up with is what Björn-Egil Dahlberg said above. The
> team is divided. Some of us just couldn't stand the growing number of
> repositories. The tree of dependencies started to be so big that it
> was a nightmare to change anything inside. Imagine that you need to
> update, say, lager version. We heavily use lager in all deps. You will
> need to update the deps list of one application, then the deps list of
> the application which is dependant on the first one, then 10
> application which depend on the latter, etc...

This is very interesting to me as I'm experimenting with the
one-repo-per-app model, having done the apps-under-libdir thing.

Have you experimented with tooling/automation to help manage the
dependencies across the various applications. E.g. a centralized list
of of company "standard" apps + versions that the various app/repos
pulled from?

In a case where I need to standardize on a version of something, as a
matter of keeping things simple, I will tend to fork that repository
to a location I can control and then refer to that from each deps
list. I happen to use git (both in github and private locations) but
any protocol supported by the build tool would work. When I need to
"rev" that dependency (bug fixes, etc.) I can just selectively
pull/merge the applicable commit or tag.

Anyway, I'm not trying to solve your team's problems here :) I'm
curious though about the specific pain points and am wondering if
there are any good alternatives to address them, short of
consolidating everything into a single repo.

> At the moment, we are still having different repos for different apps.
> But some people are already thinking to put _everything_ in one single
> repository. Not only all deps, but all projects as well :)
>
> There is no one-size-fits-all solution. Right, "In the long run,
> everything fails".
> Just don't be too religious about things. If you think that either
> approach is _the_ best, perhaps you just don't have use cases that can
> help your approach fail or your project is not big/small enough.

I don't see a religious debate emerging here -- I'm encouraged that
there are options and support for different org structures and
workflows.

One of Erlang's most compelling features IMO is the app + release
abstraction -- this is a remarkably enlightened application design. It
mirrors what happens at the operating system level. And just as
operating system ecosystems are supported by the one-repo-per-app
model -- which works, clearly -- I suspect this model can be made to
work well for Erlang projects. But I have limited experience with
complex projects -- so specific data points like yours are very
helpful.

Thanks!

Garrett