-
Notifications
You must be signed in to change notification settings - Fork 54
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
Add explicit webrick dependency #189
Add explicit webrick dependency #189
Conversation
.gitignore
Outdated
@@ -19,8 +19,6 @@ | |||
coverage | |||
# generated yardocs | |||
doc | |||
# Installed gem versions. Not stored for the same reasons as .rvmrc | |||
Gemfile.lock |
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.
Using Gemfiles inside gems
Q: What happens if I put a
Gemfile
in my gem?A: When someone installs your gem, the
Gemfile
andGemfile.lock
files are completely ignored, even if you include them inside the.gem
file you upload to rubygems.org. TheGemfile
inside your gem is only to make it easy for developers (like you) to install the dependencies needed to do development work on your gem. TheGemfile
also provides an easy way to track and install development-only or test-only gems. Read about Gemfiles in gems from the Bundler in gems page and the How to create a gem with Bundler guide.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, runbundle install
, and have passing tests. If you don't check in yourGemfile.lock
, new contributors can get different versions of your dependencies, and run into failing tests that they don't know how to fix.Q: But I have read that gems should not check in the Gemfile.lock!
A: The main advantage of not checking in your Gemfile.lock is that new checkouts (including CI) will immediately have failing tests if one of your dependencies changes in a breaking way. Instead of forcing every fresh checkout (and possible new contributor) to encounter broken builds, the Bundler team recommends either using a tool like Dependabot to automatically create a PR and run the test suite any time your dependencies release new versions. If you don't want to use a dependency monitoring bot, we suggest creating an additional daily CI build that deletes the Gemfile.lock before running
bundle install
. That way you, and others monitoring your CI status, will be the first to know about any failures from dependency changes.
https://bundler.io/guides/faq.html#using-gemfiles-inside-gems
d57f7fd
to
08d97e9
Compare
08d97e9
to
64ba704
Compare
Looks like CI fails on yard:
This repo currently pins yard to a version that doesn't support Ruby 2.7: metasploit_data_models/metasploit_data_models.gemspec Lines 31 to 33 in ac04af7
|
c0525cc
to
846d818
Compare
846d818
to
d5784d0
Compare
Metasploit data models has an implicit dependency on webrick here which breaks and must be updated to work:
Note that Webrick is no longer included in Ruby 3.0.0 by default:
https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/
rapid7/metasploit-framework#14666