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

[Garrett Smith]

On Thu, Apr 10, 2014 at 2:02 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> On 04/10, Loïc Hoguin wrote:
>> It does not support the terrible apps/* layout directly, but it's easily
>> done using a top-level Makefile like the one that was posted in that other
>> thread earlier today: https://gist.github.com/RJ/6977165
>
> There's nothing terrible for that layout. It's in fact the one used by
> OTP itself (replace 'apps' by 'lib' as a name).

Meh, I've never looked at the source tree for OTP and said, "boy, I
wish *my* project was this big and complex" :)

Nothing against OTP -- things over time get big and complex. But I'm
looking for some practical ways to curb this...

> It's, in my opinion, the most logical structure to build releases where
> you have many applications that you manage yourself. How weird would OTP
> be as a release if it had that structure?
>
>     bin/
>     bootstrap/
>     erts/
>     lib/
>         asn1
>         common_test
>         ...
>     make/
>     plt/
>     src/
>         stdlib.app
>     system/
>     ...
>
> It just doesn't always make sense to have one top-level application be
> set apart in a system. The moment you own two specific apps that may run
> at the top level, whatever they might be, the apps/* layout starts
> making sense, especially when the project is still too small to warrant
> having a separate repository just to build releases in (the way Basho
> does it for Riak, more or less).

I've historically thought along this line as well -- anything "big"
ought to have a lib/apps top level dir under which the apps live. But
I've been thinking differently recently. I'm not settled yet, but I'm
experimenting with this approach:

  | Always keep an app in a separate repo and let the rebar/erlang.mk
  | approach stitch apps together, regardless of how big the things gets.

Many folks here will reject this out of hand, claiming that the
overhead of dealing with one-app-per-repo is crazy on its face. Maybe,
but I'm trying it because I think there's some upside:

- A separate app per repo helps isolate it from others

This is more than code organization. Separate apps are easier to
stitch together in interesting combinations. The "repo" has proven
itself as a suitable container for consumption by Erlang build tools.
I want to see the point this breaks down in real life and what
specific problems arise (rather than my theoretical objections).

If anyone has experiences here, I'm very interested to learn from them.

- Big apps just keep getting bigger

We (CloudBees) have a decent sized project with over 20 apps. It's
hard to use the apps outside of it and this problem only gets worse
over time. Is it really too big to be managed using the
one-app-per-repo pattern? Dunno, but I'm curious.

- The extra cost could be a benefit - a "sin tax"

Raising the price of creating a new app will slow new app creation --
programmers will think just a little more about going down that road.
The "never duplicate code" religion gets a little poke in the eye --
it's not as easy to willy nilly break something into a "shared
library" simply to consolidate code.

Same goes for the cost of creating a dependency.

When using the one-repo-per-app trick, I satisfy dependencies on other
local apps by creating symlinks under "deps". This satisfies erlang.mk
real good and seamlessly propagates changes.

Code commits are trickier because I need to cd across apps. I have to
be careful to commit and push changes, lest they get lost in the sea
of peers. So far I haven't found this terrible but haven't seen it at
scale yet.

Garrett