[erlang-questions] Recommended approach for dependency management during development
Fri Dec 7 15:10:13 CET 2012
On Fri, Dec 7, 2012 at 7:43 AM, Vineet Naik <> wrote:
> I trying to write my first non trivial Erlang/OTP application and
> looking for the best approach for organizing and managing
> dependencies during development.
> So far there has been a single dependency for the project which
> is the exmpp library. Upon installing exmpp, it copied
> compiled code to the search path (/usr/lib/erlang/lib/) so I did
> not have to care while using it in my code.
> But now I need to use erlang-mysql-driver too and it doesn't
> come with an installation script like exmpp that would copy
> compiled files to the search path.
> Presently I can think of following ways to fix this:
> 1. Add hard coded paths of src & include dirs of the libraries in
> my Emakefile (disadvantage: wouldn't work on other machines)
> 2. Compile the code from the libraries and copy the beam files
> over to the ebin dir of my project. I need to do this only once
> as I don't plan to change their code.
> 3. Add search paths to the command every time while starting the
> Does rebar handle this and should I be using it instead of the
I would approach this in two passes:
1. Start using rebar to manage your dependencies for local development
2. Use Erlang releases to bundle your application for deployment
At build time, rebar will download and build dependencies in a local
"deps" dir. You can configure your shell start script to set ERL_LIBS
to deps to make those applications available from the shell. There's
no need to touch your system wide Erlang/OTP installation.
But that's strictly for development.
For production (deployment outside your dev environment) you really
want releases. Releases work very well. The main Erlang distribution
itself is a release.
The problem is building them.
I hear rebar works for this now, but I haven't use it. I use a
Makefile and Erlang reltool, systools -- after a lot of work hacking
through what works and what doesn't, total PITA. If rebar creates
correct, clean releases now, I'd definitely use that instead.
This is a good overview of releases:
More information about the erlang-questions