[erlang-questions] newbie question on deploying third party tools

[Geoff Cant]

Will <wglozer@REDACTED> writes:

> On Wed, Apr 29, 2009 at 6:30 AM, Larry White <ljw1001@REDACTED> wrote:
>>
>> Based on recent posts to this list, I'm interested in trying the smtp-fsm and epgsql libraries.  My general question is: How do you deploy these things?
>> More specifically, I have my own app with its own src subfolder, etc. Where do third party libraries get installed relative to something like this?
>
> On a development system it's easiest to set the ERL_LIBS environment
> variable to a PATH-like list of directories containing your libraries.
> For example I've set ERL_LIBS to ~/erlang/lib/ which contains
> directories named yaws-1.81, epgsql-1.1, etc. Another option is to put
> libraries in the lib/erlang/lib/ directory under your Erlang
> installation.
>
> For more details check out the documentation for the code module,
> http://erlang.org/doc/man/code.html.
>
>> Also, what if anything, do I then need to do to use the applications?
>
> When you're running erlang in interactive mode (the default), there's
> nothing else to do. The code server will automatically load modules
> from the code path as needed. There's also an embedded mode and boot
> scripts for production systems, which loads all modules during
> startup.

For my part I tend to use git for project source control (but anything
with externals works) and use git submodules to incorporate other
libraries into a project.

/root
     /Emakefile, Makefile -- use erl -make to build invoked from make
     /{src,ebin,include,docs,priv} -- normal project files
     /lib -- incorporated libraries
         /somelib -- git submodule

While developing, run "erl -pa ebin lib/*/ebin -s your_app" to start
your system.

The nice aspects of this approach are:
 * Most erlang libraries aren't mature - you can't often incorporate
   them directly into a build you'd deploy in production, they need
   tweaking. Whether it's adding convenience functions to the API,
   updating deprecated functions or ensuring the library works as an OTP
   app, libraries usually need tweaking.

   DVCSs are incredibly helpful here as you can maintain your small
   fixes as well as incorporate upstream changes
 * You get a reliable checkout - you can checkout the repository on
   someone elses machine, pull down the submodules/externals and build
   the entire thing, with known versions of all the source. This avoids
   having to manually find and fetch the source to all the libraries you
   incorporate and stops different developers from having different
   versions they develop with.
 * If you update a library used by one project, it won't affect some
   other project you're working on that uses the same library. Better
   yet, if you update a submodule/external, that change will be tracked
   as a commit within your source control system and will propagate to
   the other developers working on the code.

If I was confident that my github code built cleanly from a checkout I'd
give you an example of this project style here, but fate isn't usually
that kind to me. ;)

Cheers,
-- 
Geoff Cant