By default, there's a kind of assumption in rebar3 that you'll use releases to deploy your systems. If you do not, you can use the `rebar3 path' to return a list of all paths, or use specific options:
--app Comma separated list of applications to return paths for. --base Return the `base' path of the current profile. --bin Return the `bin' path of the current profile. --ebin Return all `ebin' paths of the current profile's applications. --lib Return the `lib' path of the current profile. --priv Return the `priv' path of the current profile's applications. -s, --separator In case of multiple return paths, the separator character to use to join them. --src Return the `src' path of the current profile's applications. --rel Return the `rel' path of the current profile.
So for a command like yours, you could use something like -pa `rebar3 path --separator=" -pa " to generate explicit path additions for all dependencies, or use something like `erl -env ERL_LIBS `rebar3 path --lib` and get mostly the same result. When working under a different profile (i.e. tests with new dependencies) you can go `rebar3 as test path ...' and get it to work.
The `path' task only relies on the 'app discovery' subtask, which basically means that it relies only on the ability of rebar3 to read the shape of your base repo to work. Using this task with `rebar3 get-deps' lets you use rebar3 as a tool solely dedicated to fetching and upgrading dependencies, without caring about the compilation or release phases if you were to use a different tool.
On Wed, Apr 25, 2018 at 4:02 AM, Martin Dimitrov <[hidden email]> wrote:
I am stuck with rebar3. It generates so many directories and files that I am kind of lost 😊 Previously we were starting our app as: