search

inukshuk / bibtex-ruby

A BibTeX library, parser, and converter for Ruby.
http://inukshuk.github.com/bibtex-ruby
GNU General Public License v3.0
155 stars 35 forks source link

Remove Gemfile.lock #155

Closed tmaier closed 2 years ago

tmaier commented 2 years ago

Tests failed for me, as the Gemfile.lock was outdated.

It is not recommended to commit the Gemfile.lock when developing gems.

mapreal19 commented 2 years ago

@tmaier I disagree. From https://bundler.io/guides/faq.html

Q: Should I commit my Gemfile.lock when writing a gem?

A: Yes, you should commit it. The presence of a Gemfile.lock in a gem's repository ensures that a fresh checkout of the repository uses the exact same set of dependencies every time. We believe this makes repositories more friendly towards new and existing contributors. Ideally, anyone should be able to clone the repo, run bundle install, and have passing tests. If you don't check in your Gemfile.lock, new contributors can get different versions of your dependencies, and run into failing tests that they don't know how to fix.

It is better to update the Gemfile.lock then and not remove it as a quick fix. cc @inukshuk

tmaier commented 2 years ago

You are absolutely right. I was acting based on an outdated information.. I am going to revert this.

Is it ok to just run bundle update or are special measures necessary?

inukshuk commented 2 years ago

Thanks @mapreal19 -- yes I think it's OK to leave lock file in the repository (it's excluded from the manifest file and thus excluded from the Gem).

inukshuk commented 2 years ago

With regard to bundle update there's no special measures involved that I can think of? The main issue is probably that the entire stack is very old. Generally, all dependencies are not really crucial, because they are 'only' used for development or testing (or for converting to other formats). But because there are quite a lot of tests and scripts updating or changing some of these can turn into a chore.