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

[Björn-Egil Dahlberg]

On 2014-04-13 20:25, Loïc Hoguin wrote:
> You can't run Erlang without OTP today. (You *could* after you rewrite 
> half of it, and send a couple patches to OTP, but there's no 
> alternative today.)
>
> But you can run it without ssl, or diameter, or wx, or edoc... Most 
> applications could be separated from the Erlang repository without 
> much trouble.
>
> I don't use git submodules or rebar so I can't say how it is for them.
>
> Personally when I need to change the interface of a library I first 
> make that change, tag a new version, then go to the applications and 
> bump the dependency's version. If I need to make sure this change is 
> improving the bigger application while doing it, I just create a 
> symlink and do changes in both sides at the same time. The bump in the 
> other repository doesn't often happen immediately. I usually want user 
> feedback about a new Ranch version before I make Cowboy use it, for 
> example.
>
> Quick user feedback is very important. There are a lot of people who 
> would gladly run the bleeding edge ssl application (for example) 
> rather than the one from 3 months ago, and these people give early 
> feedback that allows the ssl application to get improved faster. It's 
> currently hard to use a bleeding edge version of an app that comes 
> with Erlang, you pretty much have to run master or go through hoops to 
> extract only the ssl application (and more hoops to keep it up to date 
> possibly).
>
> There's been hints from the OTP team of going in a similar direction 
> to that already. Or perhaps it was just Bjorn-Egil the rebel. We'll see!

I'll address this point.

We have had a rigorous and inconclusive debate on the matter of 
splitting the OTP repository. The OTP team is divided. Some people are 
strongly for it, namely those who work with integration, support 
applications or "non-core" application, as well as those applications 
with a different release cycle than the OTP core. Some people are 
strongly against it since they see a rise in complexity and thus 
pragmatically against it. Work on the compiler + beam becomes a bit more 
tedious if you change instructions etc. Also the argument, it works 
right now - don't fix working stuff. I won't argue the points since I'm 
solely in the "split otp repository" corner under one assumption - a 
package manager.

At OTP I think we are at 30% for, 25% against, 45% abstains for a repo 
split. Far from a consensus at least. =)

It boils down to a need for a package manager and how or what parts of 
OTP should be part of that. As long as we don't have a package manager 
that we (OTP) are behind, supports and uses, we probably won't see a 
repository split.

// Björn-Egil, aka The Rebel

>
> On 04/13/2014 08:02 PM, Max Lapshin wrote:
>> "and will be reused in other apps"
>>
>> Separation of library into another repo brings new problem. Git
>> submodules are a never-try-again hell, rebar has its weakness in
>> managing submodules (yes, I know, pull-request or GTFO, but I haven't
>> done it).
>>
>> So extracting library into separate repo is useful when you are going to
>> reuse it into another project without other big app.
>>
>> Are you going to make erlang distribution without otp but with SSL?
>>
>