rebar.lock version control

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

rebar.lock version control

Fred Youhanaie-2
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
Reply | Threaded
Open this post in threaded view
|

Re: rebar.lock version control

Roberto Aloi-6
Hi,

Some recommendations on how to manage the rebar.lock file are contained here:

Best,

Roberto

On Sat, 7 Mar 2020 at 14:49, Fred Youhanaie <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: rebar.lock version control

Tristan Sloughter-4
In reply to this post by Fred Youhanaie-2
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
>
Reply | Threaded
Open this post in threaded view
|

Re: rebar.lock version control

Fred Youhanaie-2
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
>>
Reply | Threaded
Open this post in threaded view
|

Re: rebar.lock version control

Fred Youhanaie-2
In reply to this post by Roberto Aloi-6
Many thanks. I'm sure I've visited that page in the past, but either I'd missed it, or it was added later.

Cheers,
Fred


On 07/03/2020 13:54, Roberto Aloi wrote:

> Hi,
>
> Some recommendations on how to manage the rebar.lock file are contained here:
>
> https://www.rebar3.org/docs/workflow
>
> Best,
>
> Roberto
>
> On Sat, 7 Mar 2020 at 14:49, Fred Youhanaie <[hidden email] <mailto:[hidden email]>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: rebar.lock version control

Fred Youhanaie-2
In reply to this post by Fred Youhanaie-2

On 07/03/2020 13:53, Łukasz Niemier wrote:
>
>> Is there a general recommendation regarding this? Are there cases where the changes should be tracked?
>
> In general - you should track them for reproducible development. I am not 100% sute how the deps resolution works in Rebar3, whether it takes lock file into consideration or not, but even then - you
> probably should store it.

Thanks. That's what I was suspecting, but wasn't 100% sure.

Cheers,
Fred