-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Remove add_development_dependency
from new gems
#7222
Conversation
add_development_dependency
from new gems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It helps the real-usecase.
Does this mean |
Deprecating it is kind of tough at the moment, it's too heavily used so it would be too annoying for the community in my opinion. I think reducing its usage by making it opt-in, not opt-out, on new gems is a good start. We could revisit it in the future, and see if deprecating it makes sense by then. Regarding using groups, I'm not sure whether the distinction is useful here. Generally speaking, I think only |
@simi Are you ok with this? Thanks for all your late reviews, by the way, they are really helpful. |
@bundlerbot r+ |
7222: Remove `add_development_dependency` from new gems r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that a lot of gems in the wild use `add_development_dependency` for their development dependencies, but using `Gemfile`'s for that is more useful. ### What was your diagnosis of the problem? My diagnosis was that the current situation is due to the fact that bundler generates a gem skeleton that uses `add_development_dependency` by default. ### What is your fix for the problem, implemented in this PR? My fix is to stop using `add_development_dependency` in generated gems, and instead use the Gemfile. ### Why did you choose this fix out of the possible options? I chose this fix because it encourages better practices. Co-authored-by: David Rodríguez <[email protected]>
Build succeeded |
7237: Remove `add_development_dependency` from gemspec r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our development setup is complicated, and that we are using `add_development_dependency` even though in my opinion its usage should be discouraged. ### What was your diagnosis of the problem? My diagnosis was that our development dependencies are split between the gemspec and the `spec/support/rubygems_ext` file. We can simplify this and centralize everything in the support file. ### What is your fix for the problem, implemented in this PR? My fix is to simplify our development setup by moving everything to `spec/support/rubygems_ext`, while also getting rid of `add_development_dependency` in our gemspec. ### Why did you choose this fix out of the possible options? I chose this fix because it simplifies our setup and it further discourages usage of `add_development_dependency` (after #7222). Co-authored-by: David Rodríguez <[email protected]>
The Gemfile offers more flexibility than the gemspec in terms of gem groups and platforms. Putting the default development dependencies in the Gemfile encourages users to add their own development dependencies to the Gemfile. This is similar to the current behavior of the `bundle gem` command (see rubygems/bundler#7222). This change also fixes a corner case where using the "--skip-gemspec" and "--skip-active-record" options together would incorrectly generate a "sqlite3" dependency in the Gemfile.
What was the end-user problem that led to this PR?
The problem was that a lot of gems in the wild use
add_development_dependency
for their development dependencies, but usingGemfile
's for that is more useful.What was your diagnosis of the problem?
My diagnosis was that the current situation is due to the fact that bundler generates a gem skeleton that uses
add_development_dependency
by default.What is your fix for the problem, implemented in this PR?
My fix is to stop using
add_development_dependency
in generated gems, and instead use the Gemfile.Why did you choose this fix out of the possible options?
I chose this fix because it encourages better practices.