Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advise not to track track Gemfile.lock for gem development #74

Merged
merged 2 commits into from
Sep 22, 2017

Conversation

nilbus
Copy link
Contributor

@nilbus nilbus commented Sep 14, 2017

  • Provide an explanation
  • Update all exmaples to match

Further explanation from Bundler's author, Yehuda Katz:
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

Fixes #14
Closes #23, now obsolete

@nilbus
Copy link
Contributor Author

nilbus commented Sep 14, 2017

Of course this patch doesn't bring the entire guide up to date, but I think that's a separate endeavor that will require some more dedicated time. Some things I happened to notice while working:

  • Missing authors/emails in gemspec now make gemspecs invalid and unbuildable
  • References to rubyforge

@radar radar merged commit 3a27dad into radar:master Sep 22, 2017
@radar
Copy link
Owner

radar commented Sep 22, 2017

Thanks @nilbus! I can probably look at fixing up the other things.

@nilbus nilbus deleted the untrack-gemfile-lock branch September 23, 2017 00:31
gregburek added a commit to gregburek/sequel-caller-location that referenced this pull request Sep 27, 2017
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

> In general, a gem's Gemfile should contain the Rubygems source and
> a single gemspec line. Do not check your Gemfile.lock into version
> control, since it enforces precision that does not exist in the gem
> command, which is used to install gems in practice. Even if the
> precision could be enforced, you wouldn't want it, since it would
> prevent people from using your library with versions of its dependencies
> that are different from the ones you used to develop the gem.

radar/guides#74
cyberdelia pushed a commit to cyberdelia/sequel-caller-location that referenced this pull request Oct 2, 2017
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

> In general, a gem's Gemfile should contain the Rubygems source and
> a single gemspec line. Do not check your Gemfile.lock into version
> control, since it enforces precision that does not exist in the gem
> command, which is used to install gems in practice. Even if the
> precision could be enforced, you wouldn't want it, since it would
> prevent people from using your library with versions of its dependencies
> that are different from the ones you used to develop the gem.

radar/guides#74
@matthewd
Copy link

FYI, this is no longer the official advice... see https://github.com/bundler/bundler/issues/5879 & friends.

@radar
Copy link
Owner

radar commented Feb 14, 2018

Thanks @matthewd. Probably high time I removed this guide from this repo, as the Bundler guide is a more up-to-date copy of that same guide.

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

Successfully merging this pull request may close these issues.

3 participants