Erlang/OTP releases: rebar, release_handler, .appup, etc

[Tristan Sloughter]

Everyone using the rebar :(

http://www.metabrew.com/article/erlangotp-releases-rebar-release_handler-appup-etc

[Eric Merritt]

They use what works best for them, If thats rebar its all great. So
far, for me rebar hasn't been all that useful for OTP projects.

--
You received this message because you are subscribed to the Google
Groups "Chicago Erlang User Group" group.
To post to this group, send email to ce...@googlegroups.com.
To unsubscribe from this group, send email to ceug+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ceug?hl=en.

[Jordan Wilberding]

Looks like it was a pain in the ass for this guy, too.

JW

[Eric Newhuis (personal)]

Rebar didn't work for me.  It was super easy to use but had too much automagic for my taste.

[Dave Smith]

Eric and Eric,

Are there specific things about rebar that bugged you or could be
adjusted? I'm always looking for feedback on how to improve it as a
tool.

That said, I can appreciate the statement: "It's just not my style of
tool" -- nothing wrong with that. :)

Thanks,

D.

[Eric Merritt]

Dave,

For me its just that there is a tremendous amount of very rich
metadata in an OTP app/release. Its pretty trivial to leverage this
metadata and do 'the right thing' the vast majority of the time. Of
course, then you are constraining the project such that that metadata
must exist, ie, it becomes much more difficult to build projects that
don't include this metadata. You are trading off one thing for
another, that said Its more a question of approaches then anything
else I think.

Eric

[Eric Newhuis (personal)]

I echo this concern as well as running into some confusion over the copying of all libs into directories specific for the release.

I prefer to keep all the versioned libs in some repository since cluster management tends to be a many-to-many applications-to-nodes thing.

[Dave Smith]

Please note, all my questions are intended to better understand the
scope within which we, Erlang devs, operate in -- in the hope of
developing better tools. :)

On Sun, Sep 19, 2010 at 11:05 AM, Eric Merritt <ericbm...@gmail.com> wrote:
>  For me its just that there is a tremendous amount of very rich
> metadata in an OTP app/release. Its pretty trivial to leverage this
> metadata and do 'the right thing' the vast majority of the time. Of
> course, then you are constraining the project such that that metadata
> must exist, ie, it becomes much more difficult to build projects that
> don't include this metadata.  You are trading off one thing for

So, if I am understanding you correctly, you feel that the application
metadata (.app) requirement that rebar enforces is too much structure?
How would you/did you attack this with Sinan? It seems to me that some
of these things (such as version, app name, modules, etc) need to be
specified somewhere -- if not in the .app file then where?

As for release metadata -- yes, this is something which def. needs
work in rebar. I had hoped that using reltool would reduce the amount
of work necessary to construct a release; now I'm considering a return
to my own scripts/code for doing all the packaging. There have been
many complaints about how opaque reltool.config is -- and they are
valid complaints. Again, how would you/did you attack this problem and
what tradeoffs did you find yourself making?

Ultimately, yes, rebar and faxien/sinan are different approaches.
However, I think we can benefit by sharing gained knowledge and
continue to make Erlang and its associated, often esoteric, structures
easier to use.

D.

[Eric Newhuis (personal)]

Agreed.

Moreover I think some of the esoteric features (if I am reading between the lines assuming we're talking about appup scripts and the like)--these touch on a whole-cluster sort of devops problem that is greater than the problem of upgrading/migrating a single release.

I am actually far more concerned about how to apply error-free migrations to whole farms rather than in a single release. That problem is far more complex and I don't see a solution out there than nails the problem for Erlang.

[Martin Logan]

On Sun, Sep 19, 2010 at 2:08 PM, Dave Smith <diz...@gmail.com> wrote:

Please note, all my questions are intended to better understand the
scope within which we, Erlang devs, operate in -- in the hope of
developing better tools. :)

On Sun, Sep 19, 2010 at 11:05 AM, Eric Merritt <ericbm...@gmail.com> wrote:
>  For me its just that there is a tremendous amount of very rich
> metadata in an OTP app/release. Its pretty trivial to leverage this
> metadata and do 'the right thing' the vast majority of the time. Of
> course, then you are constraining the project such that that metadata
> must exist, ie, it becomes much more difficult to build projects that
> don't include this metadata.  You are trading off one thing for

So, if I am understanding you correctly, you feel that the application
metadata (.app) requirement that rebar enforces is too much structure?
How would you/did you attack this with Sinan? It seems to me that some
of these things (such as version, app name, modules, etc) need to be
specified somewhere -- if not in the .app file then where?

As for release metadata -- yes, this is something which def. needs
work in rebar. I had hoped that using reltool would reduce the amount
of work necessary to construct a release; now I'm considering a return
to my own scripts/code for doing all the packaging. There have been
many complaints about how opaque reltool.config is -- and they are
valid complaints. Again, how would you/did you attack this problem and
what tradeoffs did you find yourself making?

Yes, reltool is a mess. That is why we rolled our own. The second generation of faxien will be much tighter than relltool. We have talked about this before but never with any traction. Why not work together so the packages you produce are installable with faxien and can be published to the repos. Why don't we agree on a common format that is OTP complient and extended where need be? I have never thought it benefits us to develop these separate tools - are you open to that?

[Tristan Sloughter]

You mean develop these separate tools with no communication? Which I think makes perfect sense. They should work in together.

Tristan

[Dave Smith]

On Tue, Sep 21, 2010 at 1:49 PM, Martin Logan <martin...@gmail.com> wrote:
>
> Yes, reltool is a mess. That is why we rolled our own. The second generation
> of faxien will be much tighter than relltool. We have talked about this
> before but never with any traction. Why not work together so the packages
> you produce are installable with faxien and can be published to the repos.
> Why don't we agree on a common format that is OTP complient and extended
> where need be? I have never thought it benefits us to develop these separate
> tools - are you open to that?

So, I've not heard anything about the next gen of faxien...what's the
status/goals?

I'm all for ensuring our tools work together. I'm curious what
extensions would need to be made to the OTP format? Or am I
misunderstanding something?

Sorry I didn't answer this sooner -- been meaning to all week. It's
just been one of "those" weeks. :) I'll be at the Erlang Workshop next
week; maybe we can sync up then?

D.

[Martin Logan]

Definitely - will see you at the workshop and we can talk. As for extensions to OTP, better put, just advances in packaging - a tar ball is not always sufficient from an operational perspective. I will catch you up on all our goings on then.

Cheers,

Martin

--