<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/18/2016 04:22 PM, Tristan
Sloughter wrote:<br>
</div>
<blockquote
cite="mid:1458343327.2161757.553505114.0E63C3AA@webmail.messagingengine.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<tt>This use-case of rebar is an important one due to Erlang's focus<br>
on fault-tolerance. To make sure your built is robust and stable,
it<br>
requires having all your dependencies at a known state. I
understand<br>
the lock file is a method to rely on remote repositories at a
specific<br>
commit and the commit should change if the repositories history is<br>
rewritten. However, repositories can disappear or be inaccessible<br>
(in a deployment environment), and it is more dependable to have
the<br>
dependency stored along with the dependent source code<br>
(to avoid a reliance on the remote repository, due to its
potential<br>
to fail in unexpected ways).<br>
<br>
For pursuing fault-tolerance (seriously) this should be a way of
using<br>
rebar that is required functionality.<br>
<br>
I have setup rebar2 to do this in <a class="moz-txt-link-freetext" href="https://github.com/CloudI/CloudI">https://github.com/CloudI/CloudI</a><br>
but this is one area that prevents me from adopting rebar3 unless
this<br>
is easily done with using <code>'</code></tt><code>{project_app_dirs,
["external", "lib"]}'<br>
instead of '</code><code>lib_dirs' ('</code><code>lib_dirs' works
with rebar2), or some other<br>
method.<br>
</code>
</body>
</html>