rebar.lock version control
Fred Youhanaie
fly@REDACTED
Sat Mar 7 15:24:23 CET 2020
Many thanks, all clear now.
Cheers,
Fred
On 07/03/2020 14:00, Tristan Sloughter wrote:
> It is recommended to check the lock file in to source control.
>
> rebar3 resolve dependencies different from tools like mix or npm. It follows a maven model of choosing the first encounter of the dependency in the tree as it is resolving. There is no "solving" for a version that matches multiple constraints in a project. So checking in the lock file is not harmful.
>
> But note when using hex dependencies the version picked is based on the constraint on the package and not in the lock file.
>
> Some more on how rebar3 handles dependencies can be found in Adopting Erlang https://adoptingerlang.org/docs/development/dependencies/ and the rebar3.org docs https://www.rebar3.org/docs/dependencies
>
> Tristan
>
> On Sat, Mar 7, 2020, at 06:48, Fred Youhanaie wrote:
>> Hi
>>
>> In the past I've noticed that some projects have rebar.lock under
>> version control, and some don't.
>>
>> Is there a general recommendation regarding this? Are there cases where
>> the changes should be tracked?
>>
>> Thanks,
>> Fred
>>
More information about the erlang-questions
mailing list