Handling external libs with rebar

Question

I want to use some libs in my application, like https://github.com/Panmind/erlang-ruby-marshal. That repo holds an src dir, but has no .app file (because it's not an application), so I can't use get-deps.

I tried another approach, adding a libs dir in sub_dirs and added the repo as a git submodule, but rebar won't compile any of its files. I guess that rebar only compiles otp applications, but not just .erl files that aren't tied to an application.

How do you manage those kind of dependencies? I would like to avoid copying the files to my app dir, because I don't think they belong there, and I kind of like the git submodule approach, that allows me to keep track of the lib version I am using.

Consumedly

Why is it not an application? You can have an application that is just a collection of modules (by not using the {mod, ...} option). – Amblygonite

That's interesting, but since I'm pulling from an existing repository, there is no .app file. – Consumedly

Answer 1

Recent rebar supports raw option for dependencies. When this option is specific, rebar does not require the dependency to have a standard Erlang/OTP layout which assumes the presence of either "src/dependency_name.app.src" or "ebin/dependency_name.app" files (see more details here).

For example:

{deps, [
  {erlang_ruby_marshal, "",
    {git, "https://github.com/Panmind/erlang-ruby-marshal", {branch, master}},
    [raw]}
]}.

Note that rebar will now be able to fetch it, but it still won't compile it. As other commenters pointed out, there's no reason why this dependency should not have an .app file. I would fork the repository and add the .app file to it.

Mordancy

That seems like a handy thing to have. Have you considered submitting a pull request to the mainline rebar project? – Kamchatka

@clofresh, yes, I still consider doing this. I'll try to find some time this week to implement it properly -- it requires more work than my initial trivial copy-paste with 3 edits. – Mordancy

@clofresh, I took a fresh look at the problem and submitted the new version as a pull request: github.com/basho/rebar/pull/217 Feel free to leave some comments there. This may help to get it merged faster. – Mordancy

@clofresh, the patch has been finally accepted. Now it is a part of standard rebar. – Mordancy

Answer 2

This article goes through the bigger process of creating applications and releases with rebar.

More specifically, I think this option in rebar.config might be what you're looking for. The only way I've found so far is to have one entry for each application:

{sub_dirs, ["libs/app1",
            "libs/app2",
            ...]}.

This requires a bit more manual work. Unfortunately rebar is very structured around the concept of one app only, and would need some better support for caring for a repository with a bunch of equally worth applications instead of a single application.

Amblygonite

Yeah, I tried that, but rebar does not compile any erl files in libs dir. – Consumedly

To be precise, I added "libs/erlang-ruby-marshal" dir, which has the src dir, but as I said, rebar does not compile anything in there. – Consumedly

Figured out one way to do it. In my opinion, it is not entirely satisfactory as it needs manual intervention in case of adding, removing or renaming applications. – Amblygonite

I still need a .app file, and since the git submodule does not have one, the approach won't work. – Consumedly

rebar is made to work with OTP compliant applications, so if you have code that doesn't adhere to the OTP standards, you might be out of luck using rebar. – Amblygonite

Ok, but still some OTP compliant applications need simple external libraries that are provided just as .beam files. Any alternatives for Erlang application build management? I considered maven-plugin but it requires all dependencies to be packaged properly. – Bettiebettina

Answer 3

If you are using Linux, you can add the required modules as hard links, into the src directory of your application.

This is far from optimal but I have yet to find a better way to do this.

Questionless

Answer 4

Ask the Agner guys to add it to their package management system. In the process they will create a fork and convert to make the project rebar compatible. Also, the original maintainer will quite possibly integrate the changes.

Osis