| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
So they are run on bundler 1.x too.
|
| |
|
|
| |
I think this was a bad fix and it's no longer necessary.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6316: Display reason to require sudo r=colby-swandale a=okkez
This is useful for non-interactive installation with bundler.
### What was the end-user problem that led to this PR?
https://github.com/treasure-data/omnibus-td-agent/issues/166
I could not notice that bundler needs sudo privilege from logs.
So I checked bundler code.
### What was your diagnosis of the problem?
Bundler does not show the reason to need sudo privilege.
### What is your fix for the problem, implemented in this PR?
Display reason to require sudo.
### Why did you choose this fix out of the possible options?
If bundler displays reason to require sudo, we can notice permission problems as soon as possible.
Co-authored-by: Kenji Okimoto <okimoto@clear-code.com>
|
| | |
| |
| |
| | |
Because Dir#[] will return unsorted results.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
spec/bundler/bundler_spec.rb:251:25: C: Style/NumericLiteralPrefix: Use 0o for octal literals.
FileUtils.chmod(0400, "tmp/vendor/bundle/unwritable.txt")
^^^^
|
| | | |
|
| | |
| |
| |
| |
| | |
In normal case, all elements in `files` are writable.
So all elements in `files` are scanned.
|
| | |
| |
| |
| |
| |
| | |
lib/bundler.rb:372:120: C: Style/StringLiteralsInInterpolation: Prefer double-quoted strings inside interpolations.
Bundler.ui.warn "Following files may not be writable, so sudo is needed: #{unwritable_files.map(&:to_s).join(',')}"
^^^
|
| | |
| |
| |
| | |
This is useful for non-interactive installation with bundler.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6706: Clean up some specs r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs could be more readable and clean.
### What was your diagnosis of the problem?
My diagnosis was that some stuff could be more explicit, some TODO's could be removed because they're already fixed, and there should not be typos.
### What is your fix for the problem, implemented in this PR?
My fix is to make the obvious changes to fix what I diagnosed.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes the specs clear, in my opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
There's nothing particular about this spec that needs a comment over the
other specs in this same context.
|
| | | |
| | |
| | |
| | | |
And because the other specs don't need it.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6702: Better `--force` to `--redownload` transition r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was. that, while trying to run `bundle install --force` today, I was getting the error `unknown switch --force` error, and I was not sure what was causing it and what I needed to do to fix it. Also, running `bundle install --help` would show `--force` as a supported option, so that would make things even more confusing.
### What was your diagnosis of the problem?
My diagnosis was that:
* A lot of removal/renaming of options in bundler 2 are artificially linked to the `forget_cli_options` switch. To me, those changes even though they are related (stopping rememebering cli options prompted us to actually remove some unnecessary ones), they are independent, so it's not straighforward to find out that it's the `forget_cli_options` setting causing this rename to be in place.
* We should show a helpful deprecation message instead of a hard error, so the transition is easier for users.
* We should update the commands help to document newer instead of deprecated options.
* The `bundle update` command has an equivalent `--force` option that should be renamed too for sanity.
### What is your fix for the problem, implemented in this PR?
My fix to the above problems is to:
* Always keep the `--force` alias, independently of whether the `forget_cli_options` is set or not.
* Show a deprecation message when `--force` is used in bundler 2, but still keep it working as before.
* Update the commands help to use `--redownload`.
* Make the equivalent changes to the `bundle update`
### Why did you choose this fix out of the possible options?
I chose this fix because it seems like the more user friendly way going forward in my opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of hard erroring, deprecate the `--force` flag on bundler 2 to
better teach users about the replacement.
Before:
$ bundle install --force
Unknown switches '--force'
After:
$ bundle install --force
[DEPRECATED FOR 2.0] The `--force` option has been renamed to `--redownload`
Could not locate Gemfile # or whatever the expected behavior for --redownload is
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6694: Fix local spec failure r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that bundler specs won't pass on my system. One of the two failures I was getting is the spec added by #6502.
### What was your diagnosis of the problem?
My diagnosis was that my system has a similar setup as TravisCI (Linux with a ruby version manager on top), but I don't set the `TRAVIS` environment variable to run the tests. This means some trickery used in the specs to get them green on TravisCI is not applied to my local run, so specs failed.
### What is your fix for the problem, implemented in this PR?
My fix is to make this spec green independently from whether it's run on TravisCI or not. My changes also make this spec not delete any files from the rubygems installation where the specs are running. In https://github.com/bundler/bundler/pull/6502#issuecomment-403713916 @indirect said that the files being deleted here are put in there by `RVM`. However, I don't think that's accurate, it's `gem update --system` putting these files in there. So if these files should not be there, we should not put them there in the first place instead of deleting them during bundler's specs.
### Why did you choose this fix out of the possible options?
I chose this fix because the alternative would be to set the `TRAVIS` environment variable before running the specs locally, but that would mean that `bundler`'s specs would delete files from my global `rubygems` installation, which seems... no good.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ /
| | |
| | |
| | | |
There's an option to explicitly not pass lib to the LOAD_PATH.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6703: Switch from Homu to Bors mergebots r=colby-swandale a=indirect
### What was the end-user problem that led to this PR?
Our existing @bundlerbot mergebot is run by [bundlerbot-homu](https://github.com/bundler/bundlerbot-homu), which is a fork of japaric/homu-on-heroku, which is a fork of servo/homu, which is a fork of barosl/homu. Sadly, most of those forks are now unmaintained, including ours. Also, Homu sets up a list of users who are allowed to approve PRs with a list in a file on an env var, when it probably should just read the list of github users that have the permission to merge.
So the end-user problem is: unmaintained mergebot, very inconvenient to update team members.
### What was your diagnosis of the problem?
My diagnosis is that we should migrate from a Homu-based mergebot to a bors-ng-based mergebot. Bors-ng lives at [bors-ng/bors-ng](https://github.com/bors-ng/bors-ng), and has a website at [bors.tech](https://bors.tech). Bors-ng is actively maintained, easy to deploy to Heroku, doesn't lose repo and PR state when the webapp is restarted, and uses GitHub permissions to determine who can approve PRs for merging.
### What is your fix for the problem, implemented in this PR?
My fix for this problem was to fork bors-ng to the @bundler organization, modify bors-ng to respond to `@bundlerbot r+` instead of responding to `bors r+`, and change the configuration files below to support using bors instead of homu.
The bors-ng repo has already accepted our patch, and we maybe don't even need to keep the forked repo anymore.
The new mergebot lives at https://bundlerbot-bors.herokuapp.com, and has the exact same issue-comment interface as the previous mergebot.
### Why did you choose this fix out of the possible options?
I chose this fix because it lets us keep the exact same mergebot interface that we have today, while easing the maintenance burden both on updating end-user permissions and on updating the app over time, since we can simply pull and deploy the latest from `bors-ng/bors-ng` without maintaining our own specialized fork.
Co-authored-by: Andre Arko <andre@arko.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* 1-16-stable:
Version 1.16.5 with changelog
scope TruffleRuby platform specs to be RubyGems >= 2.1.0
Auto merge of #6689 - bundler:colby/fix-bundler-load-error, r=colby-swandale
Auto merge of #6695 - bundler:segiddins/6684-gvp-prefer-non-pres, r=colby-swandale
Auto merge of #6693 - eregon:truffleruby, r=colby-swandale
Auto merge of #6692 - eregon:simplify-autoload-require-deprecate, r=segiddins
Auto merge of #6688 - voxik:check-search, r=colby-swandale
Auto merge of #6682 - bundler:bundle_env_formatting, r=colby-swandale
Auto merge of #6675 - MaxLap:master, r=greysteil
Auto merge of #6669 - ChrisBr:fix_dep_proxy, r=segiddins
Auto merge of #6664 - greysteil:avoid-printing-git-error, r=colby-swandale
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=colby-swandale
[GemVersionPromoter] Prefer non-pre-release versions
### What was the end-user problem that led to this PR?
The problem was `bundle update --patch` could cause a prerelease to be resolved, when it shouldn't have been.
Closes #6684.
### What was your diagnosis of the problem?
My diagnosis was the resolver moved pre's to be first when no pre requirement was specified, but then the GVP did its own sorting.
### What is your fix for the problem, implemented in this PR?
My fix was to re-implement that "pre's go first unless they were explicitly requested" logic in the GVP.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows the GVP to properly sort versions, making it entirely correct without dependence upon the resolver.
(cherry picked from commit 87f49b2dc000b38776e6a73924e63ec090d53062)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add support for TruffleRuby
Hello,
This PR adds support for TruffleRuby in Bundler.
I searched for `rbx` and `jruby` (case-insensitive) through the codebase to find all places which need changes and where tests use specific Ruby implementations. So hopefully this PR is complete, but please tell me if I missed something.
I'd also like to test TruffleRuby in Bundler's CI, but will do this as a separate PR, as we first need the next release of TruffleRuby so that it includes the fix for https://github.com/oracle/truffleruby/issues/1413.
(cherry picked from commit 368d7594adbdf83032719011d7608545faf2d942)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Check that Bundler::Deprecate is not an autoload constant
* Otherwise, it should be defined by this file.
* The issue is bundler/deprecate.rb checks `defined? Bundler::Deprecate`
and this would normally return true since an autoload is defined for
that constant. But since the autoload file is #require-d explicitly
(by bundler/psyched_yaml and bundler/shared_helpers), MRI makes it
undefined to save this pattern. This however requires a complex
autoload implementation and is confusing to debug, so let's simplify.
* Related to https://github.com/bundler/bundler/issues/6163 and https://github.com/rubinius/rubinius/issues/3769.
### What was the end-user problem that led to this PR?
Bundler fails in TruffleRuby without this change.
We plan to fix this case in TruffleRuby, but since at least 2 Ruby implementations did not expect such a corner case, we should make the code simpler since it's easy enough in this case.
### What was your diagnosis of the problem?
See above.
### Why did you choose this fix out of the possible options?
It's simple and does not break if an extra `require "bundler/deprecate"` is later added in the codebase.
(cherry picked from commit 02af3c2def7ea1e16ad7df4842d35f4bb568ad29)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Check if 'search' is initialized.
The search was checked previously, so maybe it should be checked also at this place.
This issue was identified by Coverity scanner:
~~~
Error: FORWARD_NULL (CWE-476):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/lazy_specification.rb:77: null_check: Comparing "search" to a null-like value implies that "search" might be null-like.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/lazy_specification.rb:83: property_access: Accessing a property of null-like value "search".
# 81| search = source.specs.search(self).last
# 82| end
# 83|-> search.dependencies = dependencies if search.is_a?(RemoteSpecification) || search.is_a?(EndpointSpecification)
# 84| search
# 85| end
~~~
(cherry picked from commit 0aa5ea78c0d6cc1b843aeab603182c0d301203f2)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Remove extra new lines from `bundle env` output
### What was the end-user problem that led to this PR?
When reporting my `bundle env` for https://github.com/bundler/bundler/issues/6677, I noticed an extra blank line between the `rbenv` and the `chruby` lines. Not really a big problem, other than people like me getting distracted by those little inconsistencies.
### What was your diagnosis of the problem?
My diagnosis was that the formatting method was somewhere unintentionally printing an extra new line. After checking it out, it looks like any versions that are grabbed by shelling out to `#{tool} --version` will have this problem, since the new line from the subprocess output is included in the `bundle env` output, together with its own line returns.
### What is your fix for the problem, implemented in this PR?
My fix is to prune any trailing new lines from the output of those subprocesses.
### Why did you choose this fix out of the possible options?
I chose this fix because it seemed like the simplest way to fix the issue.
(cherry picked from commit d9ffe1ecaf459baef83f08f481a15e7f72738c81)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Handle RangeNotSatisfiable for compact index
### What was the end-user problem that led to this PR?
On ruby 2.1, bundler would try to install the latest version of psych, which is not compatible with it, instead of using an older version.
This is the error message i would get:
`Gem::RuntimeRequirementNotMetError: psych requires Ruby version >= 2.2.2. The current ruby version is 2.1.0.`
### What was your diagnosis of the problem?
Looking online, i managed to discover that there are 2 API in use, and if bundler can't use the compact index, it will not be able to detect ruby version requirements. (It might be a good idea to have a message that explain that more clearly somewhere, I found that in a random thread somewhere)
Using `bundle install --verbose`, I found out that a RangeNotSatisfiable was being returned by the `info/psych` call and it stopped the usage of the compact index. I figured out that this was because the local cache file was too long after reading te code.
I also knew that psych did a mistake in one of their release and had to yank versions in the past.
### What is your fix for the problem, implemented in this PR?
When receiving the `RangeNotSatisfiable`, instead of generating an exception which bubbles up and forces bundler to switch to the dependency API, I return the response, and test for it in th caller. When the response is that one, I trigger a retry, which reloads the whole while by not requesting a specific range.
### Why did you choose this fix out of the possible options?
It seems like the only logical fix to do in the current situation.
If the API didn't use the HTTP header stuff, it would have been more efficient to change rubygems to return the full file or just the new etag instead of a RangeNotSatisfiable. Doing so would have solved the issue for all previous versions of Bundler. But the use of caching servers and so on means that it's better to just respect HTTP and do a second query.
(cherry picked from commit 4e215b74197581de3b11cf3e2948d604da7ca2d6)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix DepProxy == method
### What was the end-user problem that led to this PR?
After implementing a new hash table strategy in JRuby, bundle is broken for JRuby. The problem is caused that the ``==`` method in bundler does not check the class of the ``other`` object. This causes problems now when calling ``==`` on object other than DepProxy or nil.
jruby/jruby#5280 travis-ci/travis-ci#9994
### What was your diagnosis of the problem?
The code crashes for anything other than DepProxy class or nil.
### What is your fix for the problem, implemented in this PR?
Checking now also that other class is the same as self.
(cherry picked from commit 1856133136a5ef75a8d42fb45b3ea7dddcad2f30)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Avoid printing git error when checking version on badly packaged version
### What was the end-user problem that led to this PR?
The problem was https://github.com/bundler/bundler/issues/6453.
### What was your diagnosis of the problem?
A use had a version of Bundler packaged with Ruby 2.5.0 in RVM, but this version didn't include Bundler's git repo or any of the ivars which should have been set. As a result, Bundler was shelling out to git even though it wasn't in a git repo.
### What is your fix for the problem, implemented in this PR?
My fix is to show a nicer result in this case (just say that the SHA is unknown)
### Why did you choose this fix out of the possible options?
I chose this fix because ensuring Bundler is always packaged correctly by others isn't possible (although it seems weird and unlikely that a version without instance variables set would be used). Falling back to a cleaner error message is marginally nicer than what we currently have, and not much work.
Fixes #6453.
(cherry picked from commit e5e260e0433e78bbc4961a6655cd96131dc9a45c)
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | | |
Fix incorrect year in changelog
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[CLI::GEM] bundle gem will generate homepage_uri and code and changelog section …
### What was the end-user problem that led to this PR?
The problem was I always have to remember how to add CHANGELOG.md when I set up a new gem.
### What was your diagnosis of the problem?
My diagnosis was that CHANGELOG.md has become enough of a community standard that it makes sense to offer it in bundle gem.
### What is your fix for the problem, implemented in this PR?
My fix is only added metadata[:changelog_uri] to generated gemspec file.
Changelog.md file is not generated by default.
### Why did you choose this fix out of the possible options?
I chose this fix because Changelog.md file format is different by projects.
|
