[erlang-questions] rebar3 dependencies

[Michael Truog]

On 03/18/2016 04:22 PM, Tristan Sloughter wrote:
> There is no built-in support for vendoring.
>
> What is the use case? Is it for developers to be able to checkout a
> single repo and begin working on the project without anything additional
> needing to be fetched?
>
This use-case of rebar is an important one due to Erlang's focus
on fault-tolerance.  To make sure your built is robust and stable, it
requires having all your dependencies at a known state.  I understand
the lock file is a method to rely on remote repositories at a specific
commit and the commit should change if the repositories history is
rewritten.  However, repositories can disappear or be inaccessible
(in a deployment environment), and it is more dependable to have the
dependency stored along with the dependent source code
(to avoid a reliance on the remote repository, due to its potential
to fail in unexpected ways).

For pursuing fault-tolerance (seriously) this should be a way of using
rebar that is required functionality.

I have setup rebar2 to do this in https://github.com/CloudI/CloudI
but this is one area that prevents me from adopting rebar3 unless this
is easily done with using |'||{project_app_dirs, ["external", "lib"]}'
instead of '||lib_dirs' ('||lib_dirs' works with rebar2), or some other
method.
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160318/fa9f95ba/attachment.htm>