You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Lock files] should always be checked into source control.
Problem
However, now that rebar.lock is tracked in git, there is a concatenation of events that lead to a problem:
configure.ac may disable some features (probably because the feature is not needed, or the libraries required to compile that feature are not available in the system). This decision is stored in vars.config. Those dependencies should not be downloaded, compiled, installed.
rebar.config disables those dependencies (thanks to rebar.config.script and vars.config)
rebar.lock still mentions those dependencies, because the file is tracked in git
rebar3 will read rebar.config and rebar.lock, and will download and attempt to compile all the dependencies, even if some dependencies are only mentioned in rebar.lock, not in rebar.config
Those downloads are useless, and in fact attempting to compile the disabled dependencies may fail.
Interestingly, Mix does not behave that way: Mix only downloads the dependencies enabled in mix.exs, and uses mix.lock only to determine what exact version to download.
Solutions
Three solutions I can see, from easier to harder:
A) Don't track rebar.lock in git. This immediately solves this problem. And tracking the file, until now does not seem to be specially required
B) In configure.ac, when some feature is disabled, in addition to store this decision in vars.config, unlock the corresponding dependency in rebar.lock
C) Modify rebar3 (or at least fill an issue in its git) to behave similarly to Mix: download only the dependencies enabled in rebar.config, and use rebar.lock only to determine what exact version to download
Solution B)
Option B) can be implemented with a patch like this:
Context
In rebar3, dependencies are defined in
rebar.config
Since commits 1a63443 and 0407c56, we can define the minimum required dependency version, and allow rebar3 to download any newer version.
The
rebar.lock
file is used to indicate what exact dependency versions are used:This file is tracked in ejabberd git repository since da8c9f3 because rebar3 documentation recommends it:
Problem
However, now that
rebar.lock
is tracked in git, there is a concatenation of events that lead to a problem:configure.ac
may disable some features (probably because the feature is not needed, or the libraries required to compile that feature are not available in the system). This decision is stored invars.config
. Those dependencies should not be downloaded, compiled, installed.rebar.config
disables those dependencies (thanks torebar.config.script
andvars.config
)rebar.lock
still mentions those dependencies, because the file is tracked in gitrebar3 will read
rebar.config
andrebar.lock
, and will download and attempt to compile all the dependencies, even if some dependencies are only mentioned inrebar.lock
, not inrebar.config
Those downloads are useless, and in fact attempting to compile the disabled dependencies may fail.
Interestingly, Mix does not behave that way: Mix only downloads the dependencies enabled in
mix.exs
, and usesmix.lock
only to determine what exact version to download.Solutions
Three solutions I can see, from easier to harder:
rebar.lock
in git. This immediately solves this problem. And tracking the file, until now does not seem to be specially requiredconfigure.ac
, when some feature is disabled, in addition to store this decision invars.config
, unlock the corresponding dependency inrebar.lock
rebar.config
, and userebar.lock
only to determine what exact version to downloadSolution B)
Option B) can be implemented with a patch like this:
For example, let's enable all the features but disable PAM, then epam will get unlocked for rebar3, and will not be downloaded:
The text was updated successfully, but these errors were encountered: