[erlang-questions] Bundle rebar with Erlang/OTP packages

[Michael Truog]

I have a script, to move dependencies into their own namespace, so that they are isolated, such that it is possible for separate versions of X to coexist.  I do not consider the solution ideal, but it seems best given the current constraints, when you want to avoid module/application conflicts with other application/module dependencies.  The script is here:
https://github.com/okeuday/reltool_util/blob/master/scope

I see the namespace concern as more of a OTP/reltool concern.  The problems with rebar are often reported, but development of rebar has been haphazard and misguided.  The rebar development does not change based on complaints, and so far no one has been willing to take the time to rewrite it. I do hope that a better solution presents itself, but I don't believe anyone is holding their breath for rebar to change after the previous years of instability.

Some simple things:
rebar could have a develop branch so that master doesn't break every-other-commit
rebar could have tags more frequently, so that testing occurs with more confidence
rebar could avoid a binary distribution, so that it could not remain an opaque binary that can not be included in a normal repository due to security concerns

There are many other problems, but they stray into specifics... these basic problems have never been addressed since rebar was first created.

On 06/11/2013 11:34 AM, Jeremy Ong wrote:
> My 2 cents.
>
> Package management and rebar come up all the time on the listserv and it will continue to come up until a viable long term solution is in place. I think the thing to fix is the underlying issue of application level namespacing. The existing dependency management system is an afterthought. If application A requires (X, v1.0) and application B requires (X, v1.1), and you want A and B to coexist, you're going to have issues.
>
> Ideally, erlang would know that when application A calls a module from X, it references the v1.0 one etc.
>
> In short, the place to start thinking about this should not be any peripheral system but incorporating it into the underlying language.
>
>
> On Tue, Jun 11, 2013 at 9:21 AM, Andrew Pennebaker <andrew.pennebaker@REDACTED <mailto:andrew.pennebaker@REDACTED>> wrote:
>
>     That's a horrible position. Windows isn't my favorite OS either, but it only hurts the Erlang commumity to dismiss support for it. There are plenty of services using a Windows  stack, and if we don't care about Windows support, Windows developers will continue to use programming languages that DO care, like Haskell.
>
>     On Jun 11, 2013 11:05 AM, "Peter Lemenkov" <lemenkov@REDACTED <mailto:lemenkov@REDACTED>> wrote:
>
>         2013/6/11 Andrew Pennebaker <andrew.pennebaker@REDACTED <mailto:andrew.pennebaker@REDACTED>>:
>         > That's nice to know!
>         >
>         > What about Windows and Mac? For some reason, rebar isn't in stable Homebrew
>         > yet, only in head.
>
>         I personally don't care about Windows users since I don't see any real
>         reason to use Erlang on Windows. Regarding Mac OS X - indeed you
>         should invest your time into enhancing package system for that
>         platform.
>         --
>         With best regards, Peter Lemenkov.
>
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130611/2d27b289/attachment.htm>