rebar generate failure

Tim Watson watson.timothy at gmail.com
Thu Jul 21 15:46:05 EDT 2011


On 21 July 2011 11:20, Robert Virding <rvirding at gmail.com> wrote:
> On 20 July 2011 02:44, Tim Watson <watson.timothy at gmail.com> wrote:
>> Another thing you might like to try is not installing 3rd party
>> libraries into the OTP lib_dir, but instead put them somewhere general
>> (like in /opt/lib/erlang or whatever) and put that directory into your
>> ERL_LIBS environment variable. There is a patch in the pipeline (not
>> yet accepted mind you) so can then put {deps_dir, ["/opt/lib/erlang"]}
>> in your global config (which using rebar from HEAD lives in
>> $HOME/.rebar/config) and have all rebar driven projects install into
>> the same deps_dir - if you want to that is.
>
> That seems like a very nice patch. Would you have a local deps_dir
> which shadows the global for the cases where you might need a specific
> version of a dep?
>
> Robert
>

Yes it think that could work, although I'd need to rework the patch a
little. One question though - why if you're installing a (more
specific?) version of a dep would you want to install it locally and
not into the global deps_dir? I would've thought that *any* version
you install should go into the global deps_dir - so only if you're
missing the required version will it get installed.

In its current incarnation (https://github.com/basho/rebar/pull/96)
local declarations of deps_dir totally override the global settings,
so you get one (directory) or the other. Remember that as far as rebar
is concerned, deps are resolved differently depending on whether there
is a source (as in {dep, Vsn, {git, "git://blah.git"}} for example) or
not. Here are the (current) rules as I understand them - probably we
should document this on the rebar wiki at some point - pertaining to
commands that depend on 'check-deps' such as 'compile'.

- A dependency is resolved by locating the lib_dir for its OTP
application and checking the version in its .app config file against
the version regex
- if you have a {dep, Vsn} tuple, rebar will fail unless the OTP
application can be found and is at the right version - it doesn't care
*where* the code is installed
- if you have a {dep, Vsn, Src} tuple, rebar will fail unless the OTP
application is found in your deps_dir

Now currently if you fetch two applications that depend on different
versions of some 3rd party library/application, you'd expect rebar to
install both versions. Here's how I think it should work:

- you build app-1 with `rebar get-deps compile`
  - this pulls libfoo-1.0.0 into your global deps_dir and compiles it
- you build app-2 with `rebar get-deps compile`
  - this pulls libbar-1.0.0 into your global deps_dir and compiles it
  - libbar-1.0.0 depends on libfoo-0.6.3 so
    - this pulls libfoo-0.6.3 into your global deps_dir and compiles it
- you build app-3 with `rebar get-deps compile`
  - this depends on libfoo-1.0.0 (or 0.6.3) which is already
installed, so nothing is fetched or compiled

The two other things I'd like to add/fix with deps are

1. Change rebar so that when it installs a dependency, it names the
directory <appname>-<version> instead of just <appname>.
2. Add support for getting deps using <= and >= some version as an
alternative (or in addition) to the regex check

Let me know if sounds correct - I'll see if the pull request is
acceptable to the developers and make any adjustments they agree are
sensible.



More information about the rebar mailing list