Skip to content
This repository has been archived by the owner on Jul 29, 2018. It is now read-only.

Put Gemfile.lock under version control #203

Closed
hferentschik opened this issue Apr 27, 2016 · 4 comments
Closed

Put Gemfile.lock under version control #203

hferentschik opened this issue Apr 27, 2016 · 4 comments
Assignees

Comments

@hferentschik
Copy link
Contributor

Adding the lock file will make the setup repeatable.

@hferentschik hferentschik self-assigned this Apr 27, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
@coolbrg
Copy link
Contributor

coolbrg commented May 9, 2016

It is not recommended to check-in Gemfile.lock while building gem.
Check here http://stackoverflow.com/a/4151540/1120530

hferentschik added a commit to hferentschik/vagrant-service-manager that referenced this issue May 9, 2016
@hferentschik
Copy link
Contributor Author

It is not recommended to check-in Gemfile.lock while building gem.

That depends. In our case we are locking down the development dependencies which makes sense imo. Also depending on your work flow having Gemfile.lock not in the repository won't help you to detect any compatibility issues (you would have to regularly delete the lock file).

@coolbrg
Copy link
Contributor

coolbrg commented May 10, 2016

As per reference of this answer http://stackoverflow.com/a/7919948/1120530.

No, the Gemfile.lock file is an aid for deployment, not for development.
It is used to recreate an exact replica of your environment on another systems, something that is not (usually) required for development.

IMO, check-in Gemfile.lock has pros and cons.
Pros : It would help in development but agree with above shared link that Gemfile.lock are an aid for deployment.
Cons: We may not know whether future version of the dependent gems will work or not since we almost freezed the gems version. Also, we may not be participating in respective upstream dependent gems development by allowing Gemfile.lock.

Adding this blog article by Yahuda Katz in support of not adding Gemfile.lock.
Highlights at the bottom of the article.

This is also why we recommend that people do not check in their Gemfile.lock 
files in gem development. That file is emitted by bundler, and guarantees that 
all gems, including dependencies of dependencies, remain the same. However, when
doing gem development, you want to know immediately when some change in the 
overall ecosystem breaks your setup. While you may want to insist on using a 
particular gem from its git location, you do not want to hardcode your development
to a very specific set of gems, only to find out later that a gem released after 
you ran bundle install, but compatible with your version range, doesn't work 
with your code.

It's not a way to guarantee that your code works on all versions that you 
specified in your .gemspec, but the incentive to lock down the exact versions of
each gem simply doesn't exist when the users of your code will get it 
via gem install.

@navidshaikh navidshaikh modified the milestone: v1.0.3 May 11, 2016
@hferentschik hferentschik removed this from the v1.1.0 milestone May 23, 2016
@hferentschik
Copy link
Contributor Author

Closing this one. If we go down the path having conditionals in the Gemfile it does not make sense anymore to check in the lock file.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants