Generally this warning is skipped for gemspec development dependencies.
I think because it's common to override them in the Gemfile to change
the source, for example.
But the order of conditions was not correct and the warning was still
being printed in one case.
da9d1d6a3f
Very often github source is used to temporarily use a modified gem
while a PR upstream is being reviewed.
So for instance https://github.com/ruby/bigdecimal/pull/211 will look like:
```ruby
gem "bigdecimal", github: "casperisfine/bigdecimal", branch: "git-gem" # https://github.com/ruby/bigdecimal/pull/200
```
It's annoying because you have to fiddle with the branch name, which is copied as `casperisfine:git-gem`, etc etc.
If I could simply use the PR URL like this:
```
gem "bigdecimal", github: "https://github.com/ruby/bigdecimal/pull/211"
```
It would make a very common task for me so much simpler.
517c527751
`check_rubygems_source_safety` is responsible for:
1. if there are multiple global sources
- for bundle 3.x raise an error
- for bundle 2.x print a warning
2. print a warning if there is no explicit global source
The second responsibility was added recently and now the logic could be
extracted to improve readability. Conditions are still live in the `check_rubygems_source_safety` method
since we don't want to call both functions always and that would help us achieve that.
f3d7e946ee
Raise a warning when parsing a Gemfile and it doesn't have a global source. Gemfiles like this, specially now that rubygems sources are are no longer merged into a single source for security, are very confusing because they generate a different lockfile depending on the gems you have locally installed. This is because bundler always use an implicit global source that defaults to locally installed gems.
b7523ad21c
When a development dependency was duplicated inside the gemspec and
Gemfile with the same requirements, we went from printing a warning to
removing the gem altogether.
This change makes it not print a warning, but don't remove the gem
either.
8bb2488131
* bin/*, lib/bundler/*, lib/bundler.rb, spec/bundler, man/*:
Merge from latest stable branch of bundler/bundler repository and
added workaround patches. I will backport them into upstream.
* common.mk, defs/gmake.mk: Added `test-bundler` task for test suite
of bundler.
* tool/sync_default_gems.rb: Added sync task for bundler.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65509 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I faced a big issue about Bundler with ruby core.
I have no time to resolve it issue before 2.5 final release.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61416 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rubygems 2.7.x depends bundler-1.15.x. This is preparation for
rubygems and bundler migration.
* lib/bundler.rb, lib/bundler/*: files of bundler-1.15.4
* spec/bundler/*: rspec examples of bundler-1.15.4. I applied patches.
* https://github.com/bundler/bundler/pull/6007
* Exclude not working examples on ruby repository.
* Fake ruby interpriter instead of installed ruby.
* Makefile.in: Added test task named `test-bundler`. This task is only
working macOS/linux yet. I'm going to support Windows environment later.
* tool/sync_default_gems.rb: Added sync task for bundler.
[Feature #12733][ruby-core:77172]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59779 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
