| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This would have made diagnosing https://github.com/bundler/bundler/issues/6220 much easier
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make `bundle clean` clean extension directories
### What was the end-user problem that led to this PR?
The problem was that `bundle clean` command doesn't remove gem extensions (#5596)
### What was your diagnosis of the problem?
I've looked into `Bundler::Runtime#clean` and realized that extension dirs are not removed
### What is your fix for the problem, implemented in this PR?
My fix is to tweak `Bundler::Runtime#clean` to remove extensions dirs
as well.
### Why did you choose this fix out of the possible options?
I chose this fix because I didn't see any other option.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
`bundle clean` command doesn't remove gem extensions, because
extensions reside out of gem directories.
This change tweaks `Bundler::Runtime#clean` to remove extensions dirs
as well.
|
| |\ \
| |/
|/|
| |
| |
| | |
Fixed typos
Found by misspell.
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
Update unencrypted http links to https
To avoid human-in-the-middle attacks
|
| | |
| |
| | |
To avoid human-in-the-middle attacks
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Man] Audit links to other manpages
### What was the end-user problem that led to this PR?
The problem was links to many of our man pages were broken.
Closes https://github.com/bundler/bundler-site/issues/355.
### What was your diagnosis of the problem?
My diagnosis was we were omitting the section in the link ID.
### What is your fix for the problem, implemented in this PR?
My fix manually updates the link IDs to be correct.
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
add `--paths` option to `bundle list` command.
See #6172
This option mimics the `--paths` options in `bundle show` which is
being removed in Bundler 2.
Example Usage:
```
$ bundle list --paths
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actioncable-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionmailer-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionpack-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionview-5.1.4
```
|
| | | | |
|
| | | |
| | |
| | |
| | | |
--only-names + --paths are used together
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This option mimics the `--paths` options in `bundle show` which is
being removed in bundler 2.
Example Usage:
$ bundle list --paths
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actioncable-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionmailer-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionpack-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionview-5.1.4
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix warning in rubygems testing re __FILE__
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?
Testing with trunk & rubygems, many warnings of:
`rubygems/lib/rubygems.rb:940: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead`
### What was your diagnosis of the problem?
Updates for warnings & 'security' in trunk are showing issues that should be addressed.
### What is your fix for the problem, implemented in this PR?
It's one line...
### Why did you choose this fix out of the possible options?
Unaware of other options...
Not sure if this will work with all ruby versions. Did not test my fork...
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
[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.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
See https://github.com/ruby/ruby/commit/0af050993e9cc55e2f58d8f4677c1521bacf5bea
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix failing examples with Ruby 2.5
Followed up https://github.com/bundler/bundler/pull/6226
|
| | | | |
| | | |
| | | |
| | | | |
2.5 or later
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Version 1.16.1
# gpg: Signature made Fri Dec 22 01:46:37 2017 +07
# gpg: using ? key C3DA1D6CEFC720FA
# gpg: Can't check signature: unknown pubkey algorithm
# Conflicts:
# lib/bundler/version.rb
# spec/commands/exec_spec.rb
# spec/realworld/double_check_spec.rb
# spec/runtime/with_clean_env_spec.rb
# spec/spec_helper.rb
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Woraround for https://github.com/travis-ci/travis-ci/issues/8892
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow test execution in paths containing dash.
PR #5036 added restriction on what characters can be contained in path,
from where the specs are executed. But they dissallows even dash, which
is hopefully handled just fine on all systems.
This patch fixes #6185 by relaxing the restriction a bit and allowing
path to contain dash.
(cherry picked from commit 5566b687c135178561f7524d3a5cb68fee56e416)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Stop overriding specs during double-checks
This fixes my test-case reproduction of #6072. I’m pretty sure it’s because
the double-check was overriding the locally installed index specs with
specs fetched from the RubyGems API, causing Bundler to conclude that the
gems aren’t installed, even though they are.
@deivid-rodriguez @y-yagi can you verify that this patch fixes the issues with `inline` that you were seeing?
(cherry picked from commit 953acf7eb7c27f8fb569713c5276e12561687d6d)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Be more precise when replacing Bundler version in lock file.
Lets say the current Bundler version is 1.16.0. If the test suite is, by a chance, executed in directory which contains such version string, this path is stored in Gemfile.lock file. Later, the test tries to replace
the version of Bundler in the lock file, but instead, it replaces the version in path. Be more careful what should be actually replaced.
This is related to #6185 although it does not resolve the original concern.
(cherry picked from commit 6cef06d19fa04e2cee5ff5faba82e98c08f08d13)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bail out of reducing depency trees on huge dependency conflict sets
### What was the end-user problem that led to this PR?
The problem is described in #6114 - An unusually large set of conflicting dependencies leads to bundler get stuck and lead to very unhealthy amounts of memory and CPU time be consumed.
### What was your diagnosis of the problem?
This happens because because a too large array is fed into Array#combination in the "reduce_trees" lambda in `version_conflict_message`.
### What is your fix for the problem, implemented in this PR?
By simply bailing out when the conflict set is bigger than a certain size,
we'll get a result that is similar to what happened in earlier bundler versions
but skip a ton of CPU cycles and memory allocations.
I've chosen the limit rather unscientifically by playing around with the result
set sizes. 15 seems to be a good compromise but really anything larger than 10
should work (and with work I mean "should not usually not have to be invoked").
### Why did you choose this fix out of the possible options?
Reducing the conflict trees has been a rather new addition to bundler, so defaulting back to the old behavior of not reducing the trees seems like an OK option. It may be possible to also optimize the reduction algorithm, but since this is very much an edge case that only happens when using Bundler slightly out of the normal procedures, I think a simple bail out is sufficient.
(cherry picked from commit fc341ed6e87b324a55719b2145f6fd6576067477)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Let users generate gemfiles inside paths whos parent contains a Gemfile
### What was the end-user problem that led to this PR?
Users are unable to generate a new Gemfile with `bundle init` if there is a Gemfile in any
parent folder.
Closes #6205
### What is your fix for the problem, implemented in this PR?
Don't use `SharedHelpers.default_gemfile` as that searches up the paths for a Gemfile. Instead only check the current directory.
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prepare to release v1.16.1
I picked merge commits targeted v1.16.1 from https://github.com/bundler/bundler/milestone/56 .
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Show warning message about binstub outside generation.
/cc @indirect
Fixes #6149.
Originated from https://github.com/bundler/bundler/issues/6149#issuecomment-347783823
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Setup custom Gemfile path before loading bundler for binstubs
### What was the end-user problem that led to this PR?
While you have several gemfiles: `Gemfile` and `Gemfile.tools`.
and generates binstubs for gems from second gemfile: `BUNDLE_GEMFILE=Gemfile.tools bundle binstubs rubocop`
when you invoke those bin `bin/rubocop`
then you see error like:
```bash
/usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:458:in `block in replace_bin_path': can't find executable rubocop for gem rubocop. rubocop is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception)
from /usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:489:in `block in replace_bin_path'
from bin/rubocop:21:in `<main>'
```
### What was your diagnosis of the problem?
When you have generated `bin/bundler` by rails or by `bundler` it has setup of `BUNDLE_GEMFILE` by default as `Gemfile` or by gemfile which has been setup on `bundle binstub bundler`.
So your binstub for rubocop could not change it.
### What is your fix for the problem, implemented in this PR?
I propose to use`BUNDLE_GEMFILE` from gem's binstub over bundler's binstub version
### Why did you choose this fix out of the possible options?
This was default behavior before #5878 introduced. Just added some fix to related PR.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Ignore to generate documentation of templates.
### What was the end-user problem that led to this PR?
When users invoke `rdoc -o rdoc lib`, it generates documentation contains template files under the `lib/bundler/template` like `rdoc/lib/bundler/templates/newgem/bin/setup_tt.html`
These files are not useful for users.
### What is your fix for the problem, implemented in this PR?
I added `.document` file to its directory.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Stop overriding specs during double-checks
This fixes my test-case reproduction of #6072. I’m pretty sure it’s because
the double-check was overriding the locally installed index specs with
specs fetched from the RubyGems API, causing Bundler to conclude that the
gems aren’t installed, even though they are.
@deivid-rodriguez @y-yagi can you verify that this patch fixes the issues with `inline` that you were seeing?
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Include bundler.gemspec in the gem because warbler breaks w/o it
f06405 caused a regression with warbler, described in #6165 and jruby/warbler#421
If the fix is ok, it should probably be cherry-picked to 1-16-stable.
### What was the end-user problem that led to this PR?
Upgrading from bundler v1.15.x to v1.16.0 causes warbler to break/abort with error.
### What was your diagnosis of the problem?
1. error message from warbler: missing file
2. see why file is missing
3. google to see if it's just me 😄
### What is your fix for the problem, implemented in this PR?
Put the missing (from warblers point of view at least) back.
### Why did you choose this fix out of the possible options?
Seems easier than to fix warbler.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=indirect
Resolver: treat dependencies with prerelease versions as slightly constrained
Fixes https://github.com/bundler/bundler/issues/6181.
In Bundler 1.15.4, the way we checked for pre-releases meant that dependencies with a lot of them sorted as more constrained than those with few/none. When we moved to our updated resolution strategy in 1.16.0 we accidentally lost that behaviour.
I'm not wild about this PR, but it fixes the resolver regression. It's unsatisfying because it would be nice to believe the resolver will always resolve performantly, regardless of the sort order thrown at it, but clearly that isn't the case.
Conceptually, this can be justified as "when two resolutions are possible, we prefer the one that does not require one dependency to be at a pre-release version".
If others are happy with this I can write a test for it.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=indirect
Fix NoMethodError during `bundle update --group`
### What was the end-user problem that led to this PR?
#6156: NoMethodError: undefined method `version' for nil:NilClass
### What was your diagnosis of the problem?
The `bundler` gem does not participate in the lockfile, but it can still be included in the list of dependencies that are being updated by `bundle update` if `--group` is specified.
For example, if a Gemfile contains `bundler-audit` (which depends on `bundler`) in the `:development` group, then updating with the option `--group=development` will naturally include `bundler` in the list of gems to evaluate for updating.
The trouble is that since `bundler` is excluded from the lockfile, searching the locked gems for a gemspec for bundler will return `nil`. This caused the following error during `bundle update`:
NoMethodError: undefined method `version' for nil:NilClass
### What is your fix for the problem, implemented in this PR?
This PR solves this bug by skipping over gems (i.e `bundler`) that are not in the lockfile when comparing gem versions at the conclusion of the upgrade command.
Fixes #6156.
### Why did you choose this fix out of the possible options?
I chose this fix because the bug seems to have been introduced by 618c09b59d1318958c23b1b0031c68c93186851a. My fix takes place within the new feature that was added in that commit, so it seems safe and unlikely to have side-effects.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rename .travis.yml.tt to travis.yml.tt.
### What was the end-user problem that led to this PR?
An installer of ruby core ignored dotfiles. and it is an inconsistency with gitignore file.
So bundled bundler fails `bundle gem` commands caused by this file.
This commit was r60122 from ruby/ruby: https://github.com/ruby/ruby/commit/5b3d137b1fd9f9f56fa6f17888ab8038906ed760
https://github.com/ruby/ruby/pull/1710
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use helper methods for relative path references in the specs
Ruby core needs to change `Spec::Path.root` and gemspec, bin, spec directories structure.
1. I changed spec directory from `spec` to `spec/bundler` because ruby core has rubyspec files under the `spec/rubyspec`.
2. I changed gemspec location to `bundler.gemspec` to `lib/bundler.gemspec`.
ref. https://bugs.ruby-lang.org/issues/12733#note-15
This pull request make we can modify root, gemspec path to flexible locations. After merging this pull request, I will add directory structure of ruby core repository to only `spec/support/path.rb`
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixed failing examples with Ruby 2.5.
(It targets 1-16-stable branch. I will create another pull request for master)
It's introduced by `URI::Generic` changes.
see https://github.com/ruby/ruby/commit/ed48bfa5e8770a345424abd7f24f94ea9bbf5973
I added a hostname to examples that expect `file:` string in result messages.
|
| | | | | | |
|
