Questioning the inclusion of gemfile.lock

[stevenringo]

Gemfile.lock was designed as a way of snapshotting current installed gems to ensure consistency between local development setups and deployment environments.

However for gems this should not be the case. (http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/), see under heading Update

I would very much argue that Octopress, while looks like an application, is more characteristic of a gem (why its not a gem is another discussion...)

I say this because local octopress installs get modified in such a way they no longer resemble the original application being used by others across the globe.

The problem with checking in Gemfile.lock is that there is no way to change gems when bugfixes are available from the original gem authors without waiting for a new version on master. If you update this yourself, you negate any benefit of having gemfile.lock in the first place.

This does not allow for updating gems that are still compliant yet without compromising the whole project.

For example, rb-fsevent is locked down to 0.4.3.1, which does not compile on my machine (10.7.4).

As soon as I removed the gemfile.lock it allowed me to install 0.9.1, which fixes those issues.

The correct action here would be to specify the desired versions in Gemfile, which is not happening at the moment. At the moment very few gems are specified with versions. Instead the version lockdown is happening via Gemfile.lock

I believe the gemfile should have references such as:

gem "rb-fsevent", "~> 0.9.1"

Let that be the mechanism for locking down gem versions, but with some latitude for upgrades if necessary.

[kenany]

This has been discussed before in #554, with bundler's website stating:

Make sure to add Gemfile.lock to your repository. This will ensure that other developers on your app, as well as your deployment environment, use exactly the same third-party code as you just installed.

Perhaps all that is needed is to update Gemfile.lock, and to do so every now and then. #446 seeks to accomplish this and fix your rb-fsevent problem.

As for your tip of how references in Gemfile should be, see #502.

[stevenringo]

@kenany We are not other developers of the app, we are consumers of it. We consume it like it we would a gem or a library. We are not all sharing the same octopress deployment. If it were a gem there would be no gemfile.lock - see the link above.

Fix #446 has not been pulled yet. So in order to get a fix we must now wait months for it, or update gemfile.lock ourselves, which then negates the point of having it. This is going completely against the grain of what bundler's supposed to help us with.

The answer is to correctly specify the desired versions of gems in the Gemfile. Not abuse of gemfile.lock for this purpose.

[imathis]

@stevenringo From my perspective, the convenience of having a Gemfile.lock is great but you make a good point. I'll consider this.

I remove the Gemfile.lock, I have to constantly test and update the app whenever a patch to any gem I rely on is released. For example, Sass recently made a change that would fit under ~> 3.1 but it broke lots of styles because of a new deprecation. I'd argue that they should have held off on that deprecation until 3.2, but still this illustrates my predicament.

If I had added rb-fsevent to ~> 0.4 you would still be in the same predicament because your problem got fixed in ~> 0.9. No matter what If we're sharing a Gemfile, I'll need to update it to allow folks to install the best version of a gem.

I do want to make Octopress into a gem which should solve lots of this, but that's a ways down the road. Designing the CLI, intelligent updating mechanisms, and writing migrations takes a long time. I agree that it is the proper future though.

[deanpcmad]

When deploying in production, the Gemfile.lock is required when doing bundle install --deployment.

If the Gemfile.lock file is not found, it shows this error - The --deployment flag requires a Gemfile.lock. Please make sure you have checked your Gemfile.lock into version control before deploying.

So, basically what I'm saying is Gemfile.lock should be kept. Why is it such a problem anyway? I agree that the Gemfile file should have the latest version, if possible, of each Gem or locked in the Gemfile, e.g gem "devise", "1.5".

[stevenringo]

@deanperry You are right, but you will get bundle.lock as soon as you run bundle install on your dev setup.
@imathis Yes I agree about the rb-fsevent, but I think that's a bad example, as it is unusual to jump version numbers like that. However keeping gemfile.lock just creates the same issue.

If one looks at the bigger picture, with Octopress the same codebase is shared between Octopress itself and the content one generates. While not ideal, I can understand why this has happened. And I think this is where the confusion has come in.

If one were to be developing on Octopress itself, then yes the gemfile.lock should be shared to ensure perfect compatibility. Otherwise I see no reason to have the vendor gemfile.lock.

[stevenh512]

rb_fsevent is actually a great example of why Gemfile.lock shouldn't be included. It's an OSX specific gem. While they're getting more and more common these days (especially for designers and developers), not everyone owns a Mac. I do everything in Linux (Ubuntu), so the first thing I had to do before I could use Octopress was delete Gemfile.lock and edit the Gemfile to get rid of any OSX specific gems (and replace them with the equivalent Linux specific gems). 😁

[stevenringo]

@imathis The writing's on the wall... :-)

[imathis]

I'm feeling swayed :)

[imathis]

@stevenringo One hiccup. It's really hard to develop this project without a Gemfile.lock. I don't want to add it to the .gitignore obviously, but it's a pain to keep untracked files in my repository. Any suggestion on how to overcome this?

[stevenringo]

Have a look at the skip-worktree and assume-unchanged switches for the git update-index command
http://git-scm.com/docs/git-update-index
I think it might be skip-worktree that you need.

[imathis]

@stevenringo thanks, I'll have a look. I'm actually finding it easier than I thought it'd be given that I usually do development in other branches and merge changes into the release branch. So far git seems to handle removing the Gemfile.lock when I switch to the release branch and adding it back when I switch to a development branch. Anyway, thanks for the push. This will be better I think.

[Neil-Smithline]

I had to change Gemlock.file in my install to get anything to work. My rake is at 0.9.2.2 while the Gemlock.file specified 0.9.2.