| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| | |
* The first spec fails on master, and passes with the changes in the
two previous commits.
|
| | | |
|
| |/
|
|
|
|
| |
* Non-US-ASCII characters make little sense in a binary encoding.
* Reuse helper for load_gemspec_uncached, see
https://github.com/bundler/bundler/pull/6599/files
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix typos detected by github.com/client9/misspell
### What was the end-user problem that led to this PR?
Fixing typos is sometimes very hard. It's not so easy to visually review them. Recently, I discovered a very useful tool for it, [misspell](https://github.com/client9/misspell).
This pull request fixes minor typos detected by [misspell](https://github.com/client9/misspell).
I've ignored the past changelogs and false positives. If you would like me to work on other files as well, let me know.
#### before
```
$ misspell .
bundler.gemspec:38:32: "automatiek" is a misspelling of "automate"
Rakefile:324:11: "automatiek" is a misspelling of "automate"
Rakefile:326:2: "Automatiek" is a misspelling of "Automate"
Rakefile:333:2: "Automatiek" is a misspelling of "Automate"
Rakefile:340:2: "Automatiek" is a misspelling of "Automate"
Rakefile:347:2: "Automatiek" is a misspelling of "Automate"
Rakefile:365:42: "automatiek" is a misspelling of "automate"
Rakefile:366:42: "automatiek" is a misspelling of "automate"
Rakefile:367:37: "automatiek" is a misspelling of "automate"
Rakefile:368:53: "automatiek" is a misspelling of "automate"
doc/development/RELEASING.md:58:5: "reposity" is a misspelling of "repository"
lib/bundler/vendor/thor/lib/thor/base.rb:116:70: "responsable" is a misspelling of "responsible"
lib/bundler/vendor/thor/lib/thor/util.rb:30:64: "responsable" is a misspelling of "responsible"
spec/runtime/setup_spec.rb:884:15: "succesfully" is a misspelling of "successfully"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/gems/bundler-1.12.3.gem/GET/response:193:467: "nkwo" is a misspelling of "know"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/bundler-1.12.3.gem/GET/response:193:467: "nkwo" is a misspelling of "know"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/diff-lcs-1.3.gem/GET/response:132:127: "Tje" is a misspelling of "The"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/rack-2.0.1.gem/GET/response:572:234: "adn" is a misspelling of "and"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/rack-2.0.1.gem/GET/response:831:39: "NTO" is a misspelling of "NOT"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/specs.4.8.gz/GET/response:4371:940: "ADN" is a misspelling of "AND"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/specs.4.8.gz/GET/response:6338:370: "WIH" is a misspelling of "WITH"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/specs.4.8.gz/GET/response:1790:150: "WIH" is a misspelling of "WITH"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/specs.4.8.gz/GET/response:2017:85: "TJE" is a misspelling of "THE"
```
#### after
```
$ misspell .
Rakefile:324:11: "automatiek" is a misspelling of "automate"
Rakefile:326:2: "Automatiek" is a misspelling of "Automate"
Rakefile:333:2: "Automatiek" is a misspelling of "Automate"
Rakefile:340:2: "Automatiek" is a misspelling of "Automate"
Rakefile:347:2: "Automatiek" is a misspelling of "Automate"
Rakefile:365:42: "automatiek" is a misspelling of "automate"
Rakefile:366:42: "automatiek" is a misspelling of "automate"
Rakefile:367:37: "automatiek" is a misspelling of "automate"
Rakefile:368:53: "automatiek" is a misspelling of "automate"
bundler.gemspec:38:32: "automatiek" is a misspelling of "automate"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/gems/bundler-1.12.3.gem/GET/response:193:467: "nkwo" is a misspelling of "know"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/diff-lcs-1.3.gem/GET/response:132:127: "Tje" is a misspelling of "The"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/bundler-1.12.3.gem/GET/response:193:467: "nkwo" is a misspelling of "know"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/specs.4.8.gz/GET/response:4371:940: "ADN" is a misspelling of "AND"
spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/specs.4.8.gz/GET/response:6338:370: "WIH" is a misspelling of "WITH"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/rack-2.0.1.gem/GET/response:572:234: "adn" is a misspelling of "and"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/gems/rack-2.0.1.gem/GET/response:831:39: "NTO" is a misspelling of "NOT"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/specs.4.8.gz/GET/response:1790:150: "WIH" is a misspelling of "WITH"
spec/support/artifice/vcr_cassettes/realworld/rubygems.org/specs.4.8.gz/GET/response:2017:85: "TJE" is a misspelling of "THE"
spec/support/artifice/vcr_cassettes/realworld/index.rubygems.org/versions/GET/response:10887:60: "ect" is a misspelling of "etc"
```
### What was your diagnosis of the problem?
### What is your fix for the problem, implemented in this PR?
### Why did you choose this fix out of the possible options?
Read the first part.
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
Update vendored Molinillo to 0.6.6
See https://github.com/CocoaPods/Molinillo/releases/0.6.6
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=colby-swandale
[Settings] Append the ruby scope on Bundler 2 with a global path setting
### What was the end-user problem that led to this PR?
The problem was `bundle config path` behaving differently depending on whether the config is local or global was... confusing.
Closes https://github.com/bundler/bundler/issues/6619#issuecomment-405460114.
### What was your diagnosis of the problem?
My diagnosis was setting the `path` setting should be consistent, regardless of the level of configuration it is set at.
### What is your fix for the problem, implemented in this PR?
My fix appends the "ruby scope" to the path when set globally on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it means users won't have to re-install gems when switching rubies with a global `BUNDLE_PATH` set.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix singular groups on injecting gem
### What was the end-user problem that led to this PR?
The problem was that on adding a gem to a group via
```bash
bundle add rack --group=dev
```
It gets added as
```ruby
gem "rack", :group => [:dev]
```
It should rather be
```ruby
gem "rack", :group => :dev
```
### What was your diagnosis of the problem?
My diagnosis was to not add single groups in the array.
### What is your fix for the problem, implemented in this PR?
My fix was to pick the element from the array of groups and append using
```ruby
":group => :#{d.groups.first}"
```
### Why did you choose this fix out of the possible options?
I chose this fix because it seemed to most appropriate.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
[Definition] Filter out unneeded gem platforms after resolving
### What was the end-user problem that led to this PR?
The problem was the lockfile would contain platform-specific gems that it didn't need
Closes https://github.com/bundler/bundler/issues/6491
### What was your diagnosis of the problem?
My diagnosis was the resolver sometimes activates platforms it doesn't need, since it can't know it won't need them
### What is your fix for the problem, implemented in this PR?
My fix is to use `SpecSet#for` to filter out gems that won't ever be used
### Why did you choose this fix out of the possible options?
I chose this fix because it isn't re-inventing the wheel!
|
| | | | |
|
| | | | |
|
| |\ \ \
| |_|/
|/| | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | | |
and --no-rdoc options at RubyGems 3.0
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Reword bundle update regression message
This pr updates the messaging for bundle update. Fix for #6584 .
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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"]
```
|
| | | | | | |
|
