Rebar3: How to depend on the top-level project in examples?

Questions / Help
1

I’ve got a library project which contains some examples.

  • mylib is a rebar-managed library project.
  • mylib/examples/foo is an example that uses mylib, also managed with rebar.

So, mylib/examples/foo/rebar.config has a dep that refers to mylib. So that I can make changes to mylib and have that reflected in the examples immediately, I added mylib/examples/foo/_checkouts/mylib → ../../...

But: ErlangLS (as of last week’s release) really doesn’t like the circular symlink (see els_server deadlocks/hangs in filelib:wildcard · Issue #1569 · erlang-ls/erlang_ls · GitHub).

Is there a recommended way to have an example depend on its top-level application?

I don’t want to use an umbrella, because that would require git_subdir, and erlang.mk (which we’re using elsewhere) doesn’t like those (see case_clause in dep_autopatch_rebar.erl when transforming git_subdir · Issue #1004 · ninenines/erlang.mk · GitHub).

2

As an alternative to _checkouts and symlinks, we have use something akin to GitHub - benoitc/rebar3_path_deps: A rebar plugin to specify path dependencies. in the past, would that be an option here?

3

This is what we did in cowboy_swagger: A rebar.config.script.
It’s a hack, just like yours, and it looks like this…

%% To avoid specifying a version we add cowboy_swagger in the
%% _checkouts directory.
os:cmd("mkdir _checkouts; ln -s $PWD/.. _checkouts/cowboy_swagger").

%% Return the original rebar3 configuration.
CONFIG.

:person_shrugging:

4

Unfortunately, this will create the circular symlink that upsets erlang-ls. It didn’t occur to me to use a config script, though, which might be one part of the solution.

5

As it stands, no – it doesn’t seem to like that the path is specified as "../..".

Ideally, I think I’d need some kind of plugin that creates a symlink from examples/foo/_build/default/mylib to (top)/_build/default/mylib. But: when I tried to do this manually, it didn’t work so well. I’ll dig into it some more later.

6

We’re using it with {path, ../<dep>} and {path, ../../<dep>} - but I guess there is something else that differs.

(Note: we’re using a simplified and bug-fixed version without access time comparisons: GitHub - SinusoidalSystems/rebar3_path_deps: A rebar plugin to specify path dependencies. but the gist should be the same…).

7

An option, but probably not one what works for you, sorry :), putting it here in case anyone with a similar issue comes across this topic, is to just include it into the top level project as additional source in a profile.

This is what I do for interop tests in grpcbox, grpcbox/interop at main · tsloughter/grpcbox · GitHub – so the key is, its not really an example application, there is no .app and it isn’t trying to show the user how an example would look, it is a different use case. In the top level rebar.config you can then put a profile and the additional src dirs and even additional deps if you need them:

1 Like
8

Thanks. This doesn’t address the original problem with examples as stated, but I do have some integration tests in a subdirectory that could use something like this.

9

…and it works extremely well (as far as I can tell) for this. Which is nice.