[erlang-questions] rebar3 dependencies

Tristan Sloughter <>
Sat Mar 19 04:00:19 CET 2016


Putting them under project_app_dirs is a bad idea. It'll mean running
tests for the project will run all those tests, breaks the ability to
use it as a dependency of another apps, you can't have the same app in
the rebar.config and expect it to know the project_app of the same name
is the actual dep, etc...

To correctly do this a plugin should be created.

-- 
  Tristan Sloughter
  

On Fri, Mar 18, 2016, at 09:43 PM, Fred Hebert wrote:
> On 03/18, Michael Truog wrote:
> >
> >While your opinion is that the approach is "bad", I see it as required for
> >stable and repeatable builds.  So we reach an impasse where it appears that
> >rebar3 is not meant to support this, unless by chance without it
> >intentionally being a use-case, which is unfortunate.
> 
> Just so I'm clear, the feature you're after here is that rebar3 should 
> be able to fetch your dependencies and build them, but you just want 
> them to be fetched and built in a different location so that you do not 
> have to go fetch them yourself?
> 
> Because you could just go and place them yourself in libs/ (and put your 
> own in apps/, or else use {project_app_dirs, ["deps/*", "apps/*", 
> "lib/*", "."]} to have a deps/ directory) and then check this in.
> 
> This would split your code from where they are built, and would tell 
> rebar3 "don't handle these, I'll do it myself", which I assume is kind 
> of the point here, isn't it?
> 
> So the only thing missing there is fetching and upgrading, although is 
> this still a thing you want since you don't necessarily control the 
> order it is done in? Is this the thing not being handled that would be 
> critical?


More information about the erlang-questions mailing list