| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix loadError occurring in nested bundle exec calls
### What was the end-user problem that led to this PR?
There is a LoadError occurring in Bundler when an application has its Gemfile installed with `--path`, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem.
If the user has some code that they're running with `bundle exec` (like a test suite) that is shelling out and executing `bundle exec` again, the user will receive an error saying that Bundler could not be loaded.
/home/travis/.rvm/gems/ruby-2.5.1/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/exe/bundle (LoadError)
The problem that's happening is that when we run `bundle exec`, Bundler will set the Ruby environment to add the path of the current version of Bundler into the `LOAD_PATH` and also require `bundler/setup`.
RUBYOPT=-rbundler/setup
RUBYLIB=/usr/local/bundle/gems/bundler-1.16.4/lib
This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed.
This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed `GEM_HOME` when the user ran Bundler with `bundle install --path`, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but then `RUBYLIB` comes into play and just overrules RubyGems to load the newer Bundler src.
This is ultimately what's giving us the weird load path that doesn't exist.
### What was your diagnosis of the problem?
See #6537 and #6629
### What is your fix for the problem, implemented in this PR?
When we set the `BUNDLE_BIN_PATH` env var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file.
### Why did you choose this fix out of the possible options?
This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated.
(cherry picked from commit 8c31a61037e2d526affb13d4fe07035e18266947)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix encoding spec from #6661 to also work 1.9.3
* String#b is Ruby 2.0+.
### What was the problem that led to this PR?
The CI is failing on the `1-16-stable` branch.
### What was your diagnosis of the problem?
The CI on master doesn't run against MRI 1.9.3, so this failure slipped in in #6661.
Probably testing against MRI 1.9.3 should be done on `master` too?
### What is your fix for the problem, implemented in this PR?
Make the spec work on 1.9.3.
cc @hsbt
(cherry picked from commit 72f27b0dd8c92159bf769a531cfa97672bf4c1e4)
|
| | |
|
| |
|
|
|
|
|
|
| |
Add new team members to gemspec authors
None
(cherry picked from commit 3a2492e42080e9d332b1f2058e549e22f3c4f304)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't mutate original error trees when determining version_conflict_message
*I know I'm messing with private APIs here, so have no right to expect this PR merged!*
Currently, when Bundler generates its error message for a version conflict, it mutates the `requirement_trees` array on the underlying `Molinillo::VersionConflict` error.
I would really like it if it didn't. Dependabot taps into that error to understand what went wrong with resolution and unlock any dependencies that are blocking resolution. The code where we do so is [here](https://github.com/dependabot/dependabot-core/blob/9abcb85ba69b408b11b56572dd13ab89d0c55b8c/lib/dependabot/file_updaters/ruby/bundler/lockfile_updater.rb#L142-L167).
I don't think that there's any downside to not mutating here. Resolution has finished (and failed) at this stage, so trying to reduce memory usage doesn't really matter.
🙏
(cherry picked from commit fc60fe4362a23254602fd4082a8d63ec5daf8106)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=deivid-rodriguez
Use UTF-8 for reading files including Gemfile
### What was the end-user problem that led to this PR?
See #6660 and https://github.com/oracle/truffleruby/issues/1410.
### What was your diagnosis of the problem?
The above issue details the problem.
### What is your fix for the problem, implemented in this PR?
To read the Gemfile and other files in Bundler with the default source encoding of Ruby, UTF-8, instead of the binary encoding which cannot interpret non-US-ASCII characters.
### Why did you choose this fix out of the possible options?
Because it's what Ruby does for other source files.
Fixes #6660.
(cherry picked from commit e71418eeb1c16aa6bad8712b0a74696a6d8f1e36)
|
| |
|
|
|
|
|
|
| |
Update vendored Molinillo to 0.6.6
See https://github.com/CocoaPods/Molinillo/releases/0.6.6
(cherry picked from commit cc25eda74bd5ff4c04e5e5973fddce364e2eab5c)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
require `etc` in Bundler#user_home
### What was the end-user problem that led to this PR?
In some cases, we are sending messages to the`Etc` library which may not be loaded.
### What was your diagnosis of the problem?
See #6640
### What is your fix for the problem, implemented in this PR?
Require the `etc` library before we use it
Fixes #6640
(cherry picked from commit 5dcfc318f2f58d81875880533a65c8b58cda5622)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't call File.realpath in a loop, single call does what we want
### What was the end-user problem that led to this PR?
We're calling `File.realpath` in a loop
### What was your diagnosis of the problem?
Single call already resolves symlinks recursively
### What is your fix for the problem, implemented in this PR?
Drop call in a loop
(cherry picked from commit 42c4609e01c0869f5341f658d2a345a8969fa3e2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer to use `--no-document` option in spec
### What was the end-user problem that led to this PR?
RubyGems will remove `--no-ri` and `--no-rdoc` options at RubyGems 3.0. But bundler spec is also broken when removing them.
* https://github.com/rubygems/rubygems/pull/2354
* https://travis-ci.org/rubygems/rubygems/jobs/402911887
### What is your fix for the problem, implemented in this PR?
To use --no-document option after RubyGems 2.0.
(cherry picked from commit 8d53c82ab384a18ce0da0524fcbef275ce4683df)
|
| |
|
|
|
|
|
|
| |
Reword bundle update regression message
This pr updates the messaging for bundle update. Fix for #6584 .
(cherry picked from commit 0c6048a47014bfb3485521c066a765960d8dcc10)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document that `bundle show [--paths]` sorts results
### What was the end-user problem that led to this PR?
The problem was that I could not tell from the manpage or documentation website whether `bundle show` and `bundle show --paths` would list gems and gem paths in the same order.
I am using `bundle show` and `bundle show --paths` to inventory gems that projects depend upon.
### What was your diagnosis of the problem?
My diagnosis was that the implementation of `bundle show` _does_ sort results by name, but that the manpage for the subcommand doesn't mention this.
### What is your fix for the problem, implemented in this PR?
My fix involved slightly editing the existing manpage for `bundle show`.
### Why did you choose this fix out of the possible options?
I chose this fix because the `.ronn` file text matched the current text I was seeing via the documentation website.
(cherry picked from commit 3a54aa9cc5bb7be003b963dd17ff47f52f069901)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
select a pre-release if it's specified in the Gemfile
### What was the end-user problem that led to this PR?
The problem was #6449
Closes #6449
### What was your diagnosis of the problem?
My diagnosis was that Bundler didn't select a pre-release even if one of the dependencies of a gem was specified with a pre-release version in the Gemfile.
### What is your fix for the problem, implemented in this PR?
My fix is to change `Bundler::Resolver#requirement_satisfied_by?` so that it does not reject a pre-release if at least one of the dependencies is pre-released.
### Why did you choose this fix out of the possible options?
(cherry picked from commit a97917cdf609d8de93bd887eabdf45465019a5f2)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Respect --conservative flag when updating a dependency group
Previously, we were using `Bundler.definition.specs_for groups` to get the list of dependencies to unlock when updating a specific group. That method returns all sub-dependencies for the dependencies in the group, too, which were therefore being unlocked and --conservative was being ignored.
This PR ensures `--conservative` is respected for group updates by selecting the dependencies for the group directly from the definition instead. It adds a test to ensure we don't accidentally regress.
Fixes https://github.com/bundler/bundler/issues/6560.
(cherry picked from commit c171c54c095a241584aa03c792a9946ec8313c22)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use realpath in clean_load_path
see #6465, basically we're not rejecting `bundler_lib` because we have symlink there and real path in `$LOAD_PATH`
```
$ irb
2.5.1 :001 > require 'bundler/setup'
# what happens next will shock you
From: /real_path/.rvm/gems/ruby-2.5.1/gems/bundler-1.16.2/lib/bundler/shared_helpers.rb @ line 339 Bundler::SharedHelpers#clean_load_path:
330: def clean_load_path
331: # handle 1.9 where system gems are always on the load path
332: return unless defined?(::Gem)
333:
334: bundler_lib = bundler_ruby_lib
335:
336: loaded_gem_paths = Bundler.rubygems.loaded_gem_paths
337:
338: binding.pry
=> 339: $LOAD_PATH.reject! do |p|
340: path = File.expand_path(p)
341: path = File.realpath(path) if File.exist?(path)
342: next if path.start_with?(bundler_lib)
343: loaded_gem_paths.delete(p)
344: end
345: $LOAD_PATH.uniq!
346: end
[1] pry(#<Bundler::Runtime>)> bundler_lib
=> "/real_path/.rvm/gems/ruby-2.5.1/gems/bundler-1.16.2/lib"
[2] pry(#<Bundler::Runtime>)> loaded_gem_paths
=> ["/symlinked_path/.rvm/gems/ruby-2.5.1@global/gems/did_you_mean-1.2.0/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/bundler-1.16.2/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/byebug-10.0.2/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/extensions/x86_64-linux/2.5.0/byebug-10.0.2",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/coderay-1.1.2/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/method_source-0.9.0/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/pry-0.11.3/lib",
"/symlinked_path/.rvm/gems/ruby-2.5.1/gems/pry-byebug-3.6.0/lib",
"/real_path/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.0.2/lib",
"/real_path/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/psych-3.0.2/lib",
"/real_path/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0/psych-3.0.2"]
```
(cherry picked from commit 9ca3afe30272a1403782cce0d600e7411e6cf709)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add warning to docs for explicit source gotcha
See https://github.com/bundler/bundler/issues/6280 for more context.
This PR adds a warning to the Gemfile documentation to more clearly indicate that specifying an explicit source on a per-gem or block basis also makes that scoped source a global source. Also adds a recommendation that users ensure that all gems in the Gemfile are using explicit sources whenever they introduce any explicit source blocks or source directives on individual gems.
If the root cause cannot be fixed until v2, I think this gotcha should be documented in all existing bundler versions which have this behavior, which as far as I can tell is all versions supporting explicit sources via blocks/per-gem directives. I believe it merits a warning because the behavior is non-intuitive, and represents a potential security issue if it is not understood and avoided. I don't know how backporting for documentation is performed, so I'm making this PR against master for now. Please let me know if I need to do anything else.
### What was the end-user problem that led to this PR?
Unclear behavior when mixing global sources with source blocks, as outlined in https://github.com/bundler/bundler/issues/6280 . No documentation was present that described this behavior.
### What was your diagnosis of the problem?
Having docs would have been helpful!
### What is your fix for the problem, implemented in this PR?
Add documentation
### Why did you choose this fix out of the possible options?
It was suggested that I make a PR to add documentation here: https://github.com/bundler/bundler/issues/6280#issuecomment-400535496
## To Reproduce
```ruby
source 'https://code.stripe.com/'
source 'https://rubygems.org' do
gem 'fattr'
end
gem 'mime-types'
```
results in this warning on v1.16.2, telling me that it preferred https://rubygems.org for the `mime-types` gem, which is counterintuitive when looking at the Gemfile.
```
Warning: the gem 'mime-types' was found in multiple sources.
Installed from: https://rubygems.org/
Also found in:
* https://code.stripe.com/
You should add a source requirement to restrict this gem to your preferred source.
For example:
gem 'mime-types', :source => 'https://rubygems.org/'
Then uninstall the gem 'mime-types' (or delete all bundled gems) and then install again.
```
Here is a Dockerfile that reproduces the issue when built, for source blocks:
```Dockerfile
FROM ruby:2.5.1-alpine
WORKDIR /test
RUN echo $'\n\
source "https://code.stripe.com/" \n\
source "https://rubygems.org" do \n\
gem "fattr" \n\
end \n\
gem "mime-types" \n\
' >> ./Gemfile
RUN bundle install --verbose
# the source ambiguity warning doesn't show up on the initial install for some reason
RUN rm -rf /usr/local/bundle/**/*
RUN bundle install
RUN cat Gemfile
```
Here is another Dockerfile that reproduces the issue when built, for a source directive on an individual `gem` function call:
```Dockerfile
FROM ruby:2.5.1-alpine
WORKDIR /test
RUN echo $'\n\
source "https://code.stripe.com/" \n\
gem "fattr", source: "https://rubygems.org" \n\
gem "mime-types" \n\
' >> ./Gemfile
RUN bundle install --verbose
# the source ambiguity warning doesn't show up on the initial install for some reason
RUN rm -rf /usr/local/bundle/**/*
RUN bundle install
RUN cat Gemfile
```
(cherry picked from commit d6e19e5b20bc561219650dd2b35808294600c798)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More flexible stub
### What was the end-user problem that led to this PR?
My problem is that I can't get https://github.com/rubygems/rubygems/pull/2332 CI passing.
### What was your diagnosis of the problem?
My diagnosis was that current bundler test don't support my changes in that PR, because previously the `validate` method in `rubygems` would be called without arguments, and now it's called with two arguments.
### What is your fix for the problem, implemented in this PR?
My fix is to make the specification stub more flexible so it supports any number of arguments.
### Why did you choose this fix out of the possible options?
I chose this fix because it supports my changes and doesn't break the previous version either.
(cherry picked from commit b8fdc4ae2318369a7cd71eabcdc611162fa2fee6)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=colby-swandale
Respect encodings when reading gemspecs
This PR fixes #6598. Thanks @eregon for the help and the explanation that helped me understand the issue :)!
### What was the end-user problem that led to this PR?
On gems using UTF-8 symbols defined in other files in their gemspecs, `bundle install` would crash.
### What was your diagnosis of the problem?
The problem was that since #6279 gemspecs are read binarily. However, files required from them as read as text. That means that the constants defined on those files and used in the gemspec are interpreted different and thus don't match.
### What is your fix for the problem, implemented in this PR?
My fix is to go back to reading gemspec as text again. Explictly passing the encoding when reading them still fixes the problem that the PR introducing the regression was meant to fix.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem, and keeps the situation that the PR introducing the regression fixed also working.
(cherry picked from commit cb18acc2983b6ef11d6710d8b5ef15134922ca60)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support URI::File of Ruby 2.6
### What was the end-user problem that led to this PR?
When users use file protocol with bundler, URI of Ruby 2.6 will raise auth info assignment and normalize host parameter given localhost variable with its case.
### Why did you choose this fix out of the possible options?
URI behavior of Ruby 2.6 is reasonable for me. Because I will fix this problem on bundler side.
(cherry picked from commit c3e00619a5ce34ef14b57b33278f13969ac276e7)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handle Errno::ENOTSUP in the Bundler process lock
### What was the end-user problem that led to this PR?
Bundler is trying to perform an operation on an NFS that is raising an exception (Errno::ENOTSUP)
### What was your diagnosis of the problem?
See #6566
### What is your fix for the problem, implemented in this PR?
Catch the exception and allow Bundler to continue
### Why did you choose this fix out of the possible options?
This conforms with the existing pattern in regards to handling these types of errors in the Bundler process lock logic.
(cherry picked from commit e87e499f9461ee5e00ef2f3cad600dac82152934)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check if source responds to `#remotes` before printing gem install error message
### What was the end-user problem that led to this PR?
There is a bug that was introduced in #6211 that prints an error message during `bundle install` if a gem failed to be installed. The error message attempts to call the `#remotes` method on `Bundler::Source::Git` which it does not implement.
### What was your diagnosis of the problem?
See #6563
### What is your fix for the problem, implemented in this PR?
Check if the `source` responds to `#remotes` before and return early
### Why did you choose this fix out of the possible options?
This seems to be the most simplest fix without having to refactor a lot of code.
(cherry picked from commit f358c36b580723a39c7dd72fafd883e59d9b05df)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't fallback to tempdir when required directories exist.
### What was the end-user problem that led to this PR?
When running Omnibus packaged software with updated bundler, a warning is displayed because the home folder is not owned by the user:
```
`/var/opt/gitlab` is not writable.
Bundler will use `/tmp/bundler/home/root' as your home directory temporarily.
```
There are valid reasons why this is desired, and I don't have control over it. What I can do is create the required folders used by bundler and provide them with the right permissions.
See https://github.com/bundler/bundler/issues/6546
### What was your diagnosis of the problem?
In practice instead of asking for permission on a higher level, if required folders are present and they have the right permissions, we shouldn't fallback to warning + temp directory, we should just use what is provided.
### What is your fix for the problem, implemented in this PR?
When home directory is not writable, but the required .gem and .bundle
are, we should use them instead of falling back to use tempdirs.
This creates a workaround for more restrictive setups using Omnibus
Docker or any hardened setup, to overcome the annoyances introduced by #4951.
### Why did you choose this fix out of the possible options?
This allows for distributions, package maintainers, etc to provide an alternative while keeping their hardenings requirements.
When provided the required folders with the required ownership/permission, we should not bother by not having any write permissions on the `$HOME` directory.
(cherry picked from commit 31b53cf987f5e737e1cddc70881d55b0eec8c38f)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add option to Bundler#mkdir_p to force Bundler to not use sudo
### What was the end-user problem that led to this PR?
There is a bug for functionality that was added in #6258. In certain scenarios, Bundler will create a folder for a temporary gem install with `root:root` permissions. This is happening because [Bundler#mkdir_p](https://github.com/bundler/bundler/blob/master/lib/bundler.rb#L377) checks for `requires_sudo?` which is creating a folder owned by `root:root` when it should be creating the folder with the current user.
### What was your diagnosis of the problem?
See #6535
I can see that Bundler is creating the `bin` folder with `root:root` permissions
```
[vagrant@localhost ~]$ ls -la /tmp/bundler20180519-24861-1y67io7rake-12.3.1/
total 4
drwx------. 3 vagrant vagrant 17 May 19 07:36 .
drwxrwxrwt. 9 root root 4096 May 19 07:36 ..
drwxr-xr-x. 2 root root 6 May 19 07:36 bin
```
### What is your fix for the problem, implemented in this PR?
Add an option for `Bundler#mkdir_p` to prevent it from using `sudo` even though `requires_sudo?` is true.
Fixes #6535
(cherry picked from commit 63f0561d8391271c4a9b0551037c4a16686c5c4e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable bundler caching for generated travis config
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
Whenever I create a gem using `bundle gem`, I always have to manually specify that I would like travis to cache bundler.
### What is your fix for the problem, implemented in this PR?
Specify `cache: bundler` in the generated .travis.yml.
(cherry picked from commit ce0ef4de8a50ce01d1db194f663a10f110eaf9f0)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use filesystem_access when reading a Gemfile
### What was the end-user problem that led to this PR?
The problem was users would see an issue template when their `Gemfile` did not have read permissions
Fixes https://github.com/bundler/bundler/issues/6541
### What is your fix for the problem, implemented in this PR?
My fix is to use `SharedHelpers.filesystem_access` when reading the Gemfile
(cherry picked from commit f7ad6118145b19bfe81220bc1070713902a49d8a)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix man page links
With a markup
[`bundle platform(1)`][bundle-platform(1)]
ronn creates this HTML fragment
<a href="bundle-platform.html"><code>bundle platform(1)</code></a>
At the same time, it generates HTML file `bundle-platform.1.html` based on the
man page section, and this results in certain inter-man-page links 404.
We resolve this inconsistency by spelling out the href attributes.
-----
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
404's on https://bundler.io.
For example, https://bundler.io/v1.16/man/bundle.1.html has the link to `bundle platform(1)`:
<img width="1061" alt="bundler__bundle" src="https://user-images.githubusercontent.com/25666/40212893-7fc73196-5a20-11e8-8964-5ca5ed9abfa2.png">
This points to https://bundler.io/v1.16/man/bundle-platform.html, but it is 404. The correct link is https://bundler.io/v1.16/man/bundle-platform.1.html.
### What was your diagnosis of the problem?
My diagnosis was...
that the document source was wrong.
### What is your fix for the problem, implemented in this PR?
My fix...
is this PR.
### Why did you choose this fix out of the possible options?
I chose this fix because...
`ronn -5 man/*.ronn` appears to generate `<a>` tags with the correct `href` attributes.
I tried serving the generated files with `bundler-site`, but I could not convince it to do so; `bundler-site`'s Rake tasks assumes the document source *always* comes from the remote `bundler/bundler`, and coming up with a way to test it seemed rather involved.
(cherry picked from commit 197ef090950cc379c0c131564154d06fdd1b9a04)
|
| |
|
|
|
|
|
|
| |
[Travis] Test against Ruby 2.5
The problem was Ruby 2.5 was released yesterday! So this updates Bundler to test against it on CI, as well as acknowledging 2.6 as a new minor.
(cherry picked from commit ab14bb1938d70cbe76a1fe1ddba64a84cee5a847)
|
| |
|
|
|
|
|
|
| |
Fix failing examples with Ruby 2.5
Followed up https://github.com/bundler/bundler/pull/6226
(cherry picked from commit dba5ba731e420b961723507899a94ac3987f431b)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix calling undefined `Gem::Util.inflate` in RubyGemsIntegration for old RubyGems versions
### What was the end-user problem that led to this PR?
RubyGems integration is calling `Gem::Util.inflate` which is not available in all supported versions of RubyGems.
### What was your diagnosis of the problem?
See https://travis-ci.org/bundler/bundler/jobs/368919903
### What is your fix for the problem, implemented in this PR?
Check if `Gem::Util` is defined, and if not, fallback to using the old way calling `inflate` in RubyGems
(cherry picked from commit 1eb812c8bdc4de6b052e2262b5d3d3d19f90d8a7)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix specs against RubyGems master
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was the specs on master are broken running against RubyGems master
### What was your diagnosis of the problem?
My diagnosis was This was broken by RubyGems changing how requirements are sorted.
### What is your fix for the problem, implemented in this PR?
My fix uses `Gem::Requirement` to get the same sorting rubygems has
### Why did you choose this fix out of the possible options?
I chose this fix because the sorting is different between rubygems versions
(cherry picked from commit 31b4b1e9ba2411b2543c14153416e1ecd2ddd15e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix failing exec spec that is blocking 1.16.2
### Overview
There is a test that is [failing in travis](https://travis-ci.org/bundler/bundler/builds/365371973) which is preventing v1.16.2 from being released. The spec in question is checking the `BUNDLER_SPEC_SUB_VERSION` env var and changes the assertion of the test depending on the stubbed version. The issue is that the 1-16-stable branch does not really use `BUNDLER_SPEC_SUB_VERSION` and the spec is assuming it's testing Bundler 2.
### What is your fix for the problem, implemented in this PR?
Checking for `BUNDLER_SPEC_SUB_VERSION` is not really necessary in the first place because the test is already scoped for Bundler 1 & 2 (using rspec tags). This PR removes the checking for `BUNDLER_SPEC_SUB_VERSION`.
(cherry picked from commit b7684c7bf91c448b8ee6bf60d39353385a51e23b)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document parameters and return value of Injector#inject
Summary: Use File.open instead of Kernel.open to avoid private method call when using Bundler::Injector in Ruby script.
### What was the end-user problem that led to this PR?
My app should allow users to install extensions at runtime. When using `Bundler::Injector`'s `inject` in a Ruby script, the internal method `append_to` fails with the error below.
Calling system('bundle inject GEM VERSION') is not feasible in my use case, since I want to inject the gem in a secondary Gemfile.
### What was your diagnosis of the problem?
The error that occurs when trying to inject a dependency through a call to `Bundler::Injector.inject`:
`bundler-1.16.1/lib/bundler/injector.rb:85:in 'append_to': private method `open' called for "Gemfile.local":String (NoMethodError)`
### What is your fix for the problem, implemented in this PR?
My fix replaces Kernel.open with File.open to open the Gemfile.
### Why did you choose this fix out of the possible options?
I chose this fix because it does not break current `bundle inject GEM VERSION` CLI behavior and does not introduce additional dependencies.
(cherry picked from commit 183c986dc89c25e332617fa3609efbed43f5df63)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=colby-swandale
Filter git uri credentials in source description
### What was the end-user problem that led to this PR?
The problem was HTTP basic auth credentials were leaking into Bundler's output when used in git sources
### What was your diagnosis of the problem?
My diagnosis was we needed to filter credentials in `Git#to_s`
### Why did you choose this fix out of the possible options?
I chose this fix because it doesn't require updating every place that uses `Source#to_s`, and is symmetric with what the rubygems source does to filter creds
(cherry picked from commit 822d5b278ecdae70912fe75517cf3cbdb1d53649)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not blow up when installing on a readonly filesystem without a hom…
…e directory
fixes https://github.com/bundler/bundler/issues/6461
```
docker run --read-only ruby ruby -r bundler/cli -e "puts Bundler::VERSION; Bundler::CLI.start(['exec', 'ruby', '-v'], :debug => true)"
/usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:193:in `rescue in tmp_home_path': `/root` is not writable. (Bundler::GenericSystemCallError)
Bundler also failed to create a temporary home directory at `/tmp/bundler/home':
There was an error accessing `/tmp/bundler/home`.
The underlying system error is Errno::EROFS: Read-only file system @ dir_s_mkdir - /tmp/bundler
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:181:in `tmp_home_path'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:172:in `user_home'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:197:in `user_bundle_path'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin.rb:99:in `global_root'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin/index.rb:73:in `global_index_file'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin/index.rb:32:in `initialize'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin.rb:78:in `new'
```
@segiddins
(cherry picked from commit 6ce1eea14bc2d9917ea67d0103e0a7f15a0b62ec)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Source::RubyGems] Allow installing when the path is `.`
### What was the end-user problem that led to this PR?
The problem was `bundle install` would fail when the path was configured to be the current working directory.
Fixes #6475.
### What was your diagnosis of the problem?
My diagnosis was `Gem::RemoteFetcher` caches `.gem` files differently when `Dir.pwd == download_dir`
### What is your fix for the problem, implemented in this PR?
My fix moves the file rubygems has downloaded to the cache directory we expect.
### Why did you choose this fix out of the possible options?
I chose this fix because it does not re-implement logic in rubygems, and it keeps the directory structure bundler generates consistent.
(cherry picked from commit ba49ed283fa20d313f95cdefcd32f8f82a786c9f)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bundle lock when default gemfile is present
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was on running `bundle lock --lockfile=AlternativeGemfile.lock` if a default lockfile already exists then `AlternativeGemfile.lock` is not created.
### What was your diagnosis of the problem?
My diagnosis was that the [lock](https://github.com/bundler/bundler/blob/master/lib/bundler/definition.rb#L340) function does not check the file but for contents, so a new file is not created in case of an existing lockfile.
### What is your fix for the problem, implemented in this PR?
My fix was to check for the file existence.
Closes #6460
(cherry picked from commit cecdfdb5b2a76133b0a83093ff6d80d1ffd97b46)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bump the bundle_binstub check-length to 300 characters
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
I could not start a binstub binary.
### What was your diagnosis of the problem?
Some packaging systems require modifications to the hash-bang
interpreter path, making them longer than normal. One such example of
this is the habitat-sh/habitat project. The result is that the 150
character limit does not find the regex it is looking for, and prevents
an otherwise valid binary from starting.
### What is your fix for the problem, implemented in this PR?
This change doubles the length of the check from 150 characters to 300
characters. This change has been validated in an impacted environment.
### Why did you choose this fix out of the possible options?
It was the most straightforward.
(cherry picked from commit fb38825ead6603588dae17b34b23f282548ee425)
|
| |
|
|
|
|
|
|
| |
Added license info to main README
Thought about doing this for a while but completely forgot about it. Added a link out to the MIT license from the bottom of the README. (Since it's considered a general best practice for info to be included in a README, and want to make sure the README is as complete as possible.)
(cherry picked from commit 257fb54da0003c3a67f6e7b3b5a242a4ba9c45cb)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document the order Bundler loads settings
Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was...
...[confusion from end users](https://github.com/bundler/bundler/issues/6270) about the order that Bundler loads settings in.
Before:
```
This command allows you to interact with bundler's configuration system.
Bundler retrieves its configuration from the local application (`app/.bundle/config`),
environment variables, and the user's home directory (`~/.bundle/config`),
in that order of priority.
```
### What was your diagnosis of the problem?
My diagnosis was...
...[Colby pointed out how the bundle-config doc](https://github.com/bundler/bundler/issues/6334) needed to be updated to reflect this. After reviewing the `bundle-config` doc, it appears there was some information about how Bundler loads config settings, but it wasn't complete and as apparent to users. So I decided to separate the graph out and document the settings as a list so users could spot that easier.
### What is your fix for the problem, implemented in this PR?
My fix...
...was to verify the order of priority of settings and write them out as a list.
After:
```
This command allows you to interact with Bundler's configuration system.
Bundler loads configuration settings in this order:
1. Local config (`app/.bundle/config`)
2. Environmental variables (`ENV`)
3. Global config (`~/.bundle/config`)
4. Bundler default config
```
### Why did you choose this fix out of the possible options?
I chose this fix because...
it was clear that the document had to be updated, and lists are easier for readability.
fixes #6334
(cherry picked from commit 8b8b9634648e9c2c58c0a97ed583f174dbcad111)
|
