| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
rather than strings
|
| |\
| |
| |
| |
| |
| | |
add welcome message for PR auto replies
This PR is adding the welcome message that will serve as the auto reply for Bundlerbot when a new PR is opened.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Completely remove the postit trampoline
### What was the end-user problem that led to this PR?
The problem was the bundler trampoline we tried to introduce never completely worked, it worked even less with bundler installed as a default gem (as we intend to do with RubyGems, like, a year ago), and it worked by doing disgusting things that we couldn't be confident would work under all circumstances.
### Was was your diagnosis of the problem?
My diagnosis was our best bet was to completely remove the trampoline from bundler itself.
We intend to address the user story of switching bundler versions in RubyGems directly, where the gymnastics required will hopefully be much less obtrusive. Additionally
### What is your fix for the problem, implemented in this PR?
My fix is to completely delete all references to trampolining / postit from Bundler and admit defeat.
### Why did you choose this fix out of the possible options?
I chose this fix because I'm unwilling to maintain the trampoline any longer, and since it's never been enabled, I feel this is my last chance to pull it from Bundler before I'm stuck maintaining code that doesn't work for all eternity. This will also _finally_ unblock me shipping RubyGems 2.7.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=colby-swandale
Remove `require "spec_helper"` from spec files
Follow up of #5634.
Since `--require spec_helper` is specified in the .rspec file, This PR will remove redundancy.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Avoid warnings in the specs on Ruby 1.8.7
### What was the end-user problem that led to this PR?
The problem was the specs had method redefinition warnings on 1.8.7.
### Was was your diagnosis of the problem?
My diagnosis was the `mkpath` hack was causing some, as well as us requiring support files by their absolute paths.
### What is your fix for the problem, implemented in this PR?
My fix requires support files by relative paths and updates rspec to 3.6, where the `mkpath` hack is unnecessary.
### Why did you choose this fix out of the possible options?
I chose this fix because it works on 1.8.7 without any adverse effects on modern rubies.
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=colby-swandale
[CLI] Dont print defaults in the command printed with --verbose
### What was the end-user problem that led to this PR?
The problem was that running `bundle lock --verbose` would print
Running `bundle lock --add-platform --remove-platform --verbose` with bundler 1.15.1
even though the platform flags were never specified. This was surfaced by https://github.com/bundler/bundler/pull/5724, which will be fixed by this PR.
### Was was your diagnosis of the problem?
My diagnosis was that default values of options were being printed.
### What is your fix for the problem, implemented in this PR?
My fix is to filter out the default values before getting Thor
### Why did you choose this fix out of the possible options?
I chose this fix because there is no way, within the `CLI` instance, to tell which flags the user has explicitly given, so I felt that filtering out those options that had default values was the next-best thing.
|
| | | | |
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a feature flag for `bundle update —source NAME` not unlocking a gem with that name
### What was the end-user problem that led to this PR?
The problem is that `bundle update --source NAME` will unlock a _gem_ with that name, in addition to the source.
### Was was your diagnosis of the problem?
My diagnosis was that we unlocked based on `spec.name` instead of `spec.source.name`.
### What is your fix for the problem, implemented in this PR?
My fix is to put this backwards-compatibility hack behind a feature flag that will turn off on 2.0.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows the current behavior to continue for those who depend upon it, but the hack will be disabled by default on 2.0, or when `unlock_source_unlocks_spec` is set to true.
|
| |/
|
|
| |
with that name
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
fix a missing space in the group conflict error message
### What was the end-user problem that led to this PR?
There is a typo in the error message that is printed to users when a user specifies a set of conflicting groups when running bundle install. There is a missing space after the first sentence.
```
› bundle install --with foo --without foo
You can't list a group in both, --with and --without.The offending groups are: foo.
```
### Was was your diagnosis of the problem?
execute `bundle install --with foo --without foo`
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[EnvironmentPreserver] Allow preserving MANPATH
### What was the end-user problem that led to this PR?
The problem was Bundler could throw an exception during setup when a gem contained manpages we were adding to `$MANPATH`.
Fixes #5730.
### Was was your diagnosis of the problem?
My diagnosis was that `$MANPATH` wasn't whitelisted as a key we preserved / were 'allowed' to override via `SharedHelpers.set_env`.
### What is your fix for the problem, implemented in this PR?
My fix is to add `$MANPATH` to that list of keys, as @jules2689 suggested. I also added some test coverage around us setting the proper man path.
### Why did you choose this fix out of the possible options?
I chose this fix because it treats that env var in the same way as others bundler sets.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Update bundle-gem.ronn
Fixed minor typo in Docs. Hope this helps!
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Eval Gemfiles one fewer time when running `bundle install`
This is just a straight port of https://github.com/bundler/bundler/pull/4952 to master from `2-0-dev`.
Unfortunately, the Gemfile is still eval'ed twice when plugins are enabled.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Create Gemfiles with an HTTPS github source defined
### What was the end-user problem that led to this PR?
The problem was that people are creating new Gemfiles that use the built-in `github` git source, which is being removed in 2.0. Additionally, it does _not_ use an encrypted connection to GitHub.
### Was was your diagnosis of the problem?
My diagnosis was that we can't change the default because of backwards compatibility, but we can encourage _new_ Gemfiles to "do the right thing".
### What is your fix for the problem, implemented in this PR?
My fix is to add our new, recommended definition of the shortcut to all bundler-generated gemfiles.
### Why did you choose this fix out of the possible options?
I chose this fix because it will only affect new Gemfiles.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add --shebang option to binstubs command
Ports https://github.com/bundler/bundler/pull/4070 to master.
bundle install `--binstubs` option is to be removed from Bundler 2.0 but
currently supports setting the shebang using the `--shebang` option.
See #1467 introducing the `--shebang` option, which with this commit
is ported to the binstubs command.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
bundle install `--binstubs` option is to be removed from Bundler 2.0 but
currently supports setting the shebang using the `--shebang` option.
See #1467 introducing the `--shebang` option, which with this commit
is ported to the binstubs command.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
[2.0] Add a feature flag to prefer gems.rb to Gemfile
With `prefer_gems_rb` set (by default on 2.0), Bundler will prefer a `gems.rb` that is in the same directory as a `Gemfile`
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
With `prefer_gems_rb` set (by default on 2.0), Bundler will prefer a `gems.rb` that is in the same directory as a `Gemfile`
|
| |\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Print build metadata when running `bundle version`
Closes #5049.
Will get all the build metadata into `bundle env` once https://github.com/bundler/bundler/pull/5703 lands, since I don't want conflicts and want to use that code for generating the "tables"
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Explicitly don’t print it with -v or —version, though
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
[Installer] Load plugin files from path gems
Closes #5429 .
Because RubyGems doesn't know about path gems before we install, we need to manually load the plugin files for the path gems we're installing. This is basically copying the logic RG uses, but scoped only to those gems that we're entirely responsible for.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | |_|_|/ /
| |/| | | | |
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
clearer, more specific wording about sponsorship and contributing
make it clear that everyone's contributions are welcome, and make it clear that Ruby Together funds contributors, but does not maintain the project directly
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
