Skip to content

Conversation

@edhzsz
Copy link
Contributor

@edhzsz edhzsz commented Dec 28, 2020

File was added as part of the fix to the logger but according to Yehuda Katz this was a mistake:

When developing a gem, use the gemspec method in your Gemfile to avoid duplication. 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.

When developing an app, check in your Gemfile.lock, since you will use the bundler tool across all machines, and the precision enforced by bundler is extremely desirable for applications.

https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

File was added as part of the fix to the logger but according to [Yehuda Katz](https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/) this was a mistake:

> When developing a gem, use the gemspec method in your Gemfile to avoid duplication. 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.

> When developing an app, check in your Gemfile.lock, since you will use the bundler tool across all machines, and the precision enforced by bundler is extremely desirable for applications.

https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
@stefanbotez
Copy link
Contributor

I think we should also add it to .gitignore to avoid adding it again.

@carlzogh
Copy link
Contributor

Agreed, let's add it to gitignore

For a library this file is better if it is not included ever:

> 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.

https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
@edhzsz
Copy link
Contributor Author

edhzsz commented Jan 21, 2021

Finally done.

@stefanbotez stefanbotez merged commit 92007b1 into main Jan 21, 2021
@edhzsz edhzsz deleted the edhzsz-delete-gemlock branch January 22, 2021 14:05
edhzsz pushed a commit that referenced this pull request Jan 22, 2021
The Gemfile.lock was removed in #11 but it was missed to be removed from the files being included in the released gem. This is breaking our integration tests and it is still attempting to publish the removed file as part of the gem.

`make pr` did not fail as it runs `bundler init` before running the unit and smoke tests.

On a clean branch, running `make integ-tests` reproduces the failure.
stefanbotez pushed a commit that referenced this pull request Jan 25, 2021
The Gemfile.lock was removed in #11 but it was missed to be removed from the files being included in the released gem. This is breaking our integration tests and it is still attempting to publish the removed file as part of the gem.

`make pr` did not fail as it runs `bundler init` before running the unit and smoke tests.

On a clean branch, running `make integ-tests` reproduces the failure.
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