summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [Definition] Avoid a group_by when not running a new resolveseg-bundler-2-specsSamuel Giddins2017-06-231-3/+3
|
* Update the version spec to handle when the specs start in the day before ↵Samuel Giddins2017-06-231-3/+1
| | | | that example is run
* Update the update spec for Bundler 2 allowing Bundler conflictsSamuel Giddins2017-06-231-1/+8
|
* Improve realworld specs on 2.0Samuel Giddins2017-06-233-15/+13
|
* [Source::Git] Print the underlying error when falling back to cached git dataSamuel Giddins2017-06-231-2/+2
|
* Get the 2.0 specs passing under 2.0Samuel Giddins2017-06-2324-149/+214
|
* [Init] Don’t create a gems.rb when a Gemfile existsSamuel Giddins2017-06-231-2/+6
|
* [Definition] Fully unlock on 2.0 when the dep in the Gemfile changesSamuel Giddins2017-06-231-3/+6
|
* Filter git credentials when a revision is missingSamuel Giddins2017-06-231-1/+1
|
* Get the specs passing in 1.0 modeSamuel Giddins2017-06-2311-37/+37
|
* [UI::Shell] Warn on STDERR in Bundler 2Samuel Giddins2017-06-232-3/+17
|
* Update the specs to pass under Bundler 2Samuel Giddins2017-06-237-31/+33
|
* [Travis] Begin testing Bundler 2Samuel Giddins2017-06-231-0/+3
|
* [Rakefile] Allow stubbing the Bundler version on travisSamuel Giddins2017-06-231-0/+12
|
* Allow filtering specs based on the bundler versionSamuel Giddins2017-06-231-0/+1
|
* Introduce a CommandExecution helper class in the specsSamuel Giddins2017-06-234-26/+77
|
* Auto merge of #5809 - bundler:seg-config-converted-value, r=indirectThe Bundler Bot2017-06-232-12/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Settings] Print pretty values for settings as their converted values, rather than strings ### What was the end-user problem that led to this PR? The problem was `bundle config` would print bool keys as strings (i.e. `true` was printed as `"true"`) ### Was was your diagnosis of the problem? My diagnosis was we needed to convert the values before formatting them ### What is your fix for the problem, implemented in this PR? My fix extracts the conversion method, and calls it in `pretty_values_for`
| * [Settings] Print pretty values for settings as their converted values, ↵seg-config-converted-valueSamuel Giddins2017-06-222-12/+26
| | | | | | | | rather than strings
* | Auto merge of #5806 - bundler:seg-dont-hit-remote-twice, r=indirectThe Bundler Bot2017-06-237-37/+80
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid hitting RubyGems remotes when all missing gems are in --without groups ### What was the end-user problem that led to this PR? The problem was we would attempt to fetch dependency info from a RubyGems remote even when it was only needed for gems whose groups were excluded. ### Was was your diagnosis of the problem? My diagnosis was that the test we had for this case was insufficient, since it checked only that `stderr` was empty, and since Bundler 1 prints errors to `stdout`... it went undetected for a year. ### What is your fix for the problem, implemented in this PR? My fix is to only report that deps are missing when they are either requested or are path/git/gemspec-sourced. ### Why did you choose this fix out of the possible options? I chose this fix because it keeps the behavior of always ensuring all git repos are checked out.
| * | [Definition] Allow installing in deployment mode when an unused path source ↵seg-dont-hit-remote-twiceSamuel Giddins2017-06-222-1/+45
| | | | | | | | | | | | is missing
| * | [SpecSet] Pass the correct raise_if_missing parameter in #materializeSamuel Giddins2017-06-221-1/+1
| | |
| * | Improve the quality spec to make error messages clickable as pathsSamuel Giddins2017-06-221-24/+24
| | |
| * | Allow not having specs available for gems that won’t be installedSamuel Giddins2017-06-224-11/+10
| |/
* | Auto merge of #5801 - jakauppila:fix_no_proxy_patch, r=segiddinsThe Bundler Bot2017-06-232-0/+17
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add explicit nil proxy arguments - Fixes no_proxy support ### What was the end-user problem that led to this PR? When the `no_proxy` environment variable is configured it is not being honored and requests for hosts that are present in the list will be sent through the proxy defined via `http_proxy` and `https_proxy`. Ultimately this means that a user utilizing the `http_proxy`, `https_proxy`, and `no_proxy` environment variables will unable to access an internal RubyGems source. ### Was was your diagnosis of the problem? The underlying `net-http-persistent` gem currently does not explicitly pass in nil arguments when a host matches a value within `no_proxy`, so when `Net::HTTP.new()` is called, it will fall back an utilize the values defined in `http_proxy` and `https_proxy`. https://github.com/drbrain/net-http-persistent/pull/88 has been submitted to add the explicit nil argument to be defined. ### What is your fix for the problem, implemented in this PR? Adding explicit nil arguments for the proxy definition for `Net::HTTP.new()` as defined by the documentation. https://ruby-doc.org/stdlib-2.4.1/libdoc/net/http/rdoc/Net/HTTP.html#method-c-new ### Why did you choose this fix out of the possible options? Per the discussion in https://github.com/bundler/bundler/issues/5781, as Bundler is currently stuck to v2.9.4 of `net-http-persistent` for now, it would be best addressed by a change to the vendored code. A PR has been submitted to `net-http-persistent` which can be pulled into Bundler when v3.x will be integrated.
| * | Add explicit nil proxy arguments - Fixes no_proxy supportJared Kauppila2017-06-222-0/+17
| | | | | | | | | | | | Add proxy environment variable tests
* | | Auto merge of #5725 - bundler:seg-default-command, r=indirectThe Bundler Bot2017-06-233-5/+25
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Default to printing a help message when `bundle` is run without arguments on 2.0 ### What was the end-user problem that led to this PR? The problem was that users unfamiliar with Bundler would run `bundle` and either install gems (if in a directory with a gemfile), or else get the error `Could not locate Gemfile`. You'd need to know to run `bundle help` or `bundle -h` to get the man page, and even that could be overwhelming (not to mention turfing you into a pager). ### Was was your diagnosis of the problem? My diagnosis was that we ought to print some form of help when the bare `bundle` command is run, rather than defaulting to running `bundle install`. This work was prompted by https://trello.com/c/OpuOdTZl/112-print-help-when-bundle-is-run-without-arguments, and is an improvement (rather than a straight port) on https://github.com/bundler/bundler/pull/3831. ### What is your fix for the problem, implemented in this PR? My fix was to print the following help output when the CLI is invoked without arguments, contingent upon a feature flag. ``` Bundler version 1.15.1 Commands: bundle add GEM VERSION # Add gem to Gemfile and run bundle install bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory bundle config NAME [VALUE] # retrieve or set a configuration value bundle console [GROUP] # Opens an IRB session with the bundle pre-loaded bundle doctor [OPTIONS] # Checks the bundle for common problems bundle env # Print information about the environment Bundler is running under bundle exec [OPTIONS] # Run the command in context of the bundle bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem bundle help [COMMAND] # Describe available commands or one specific command bundle help [COMMAND] # Describe subcommands or one specific subcommand bundle info GEM [OPTIONS] # Show information for the given gem bundle init [OPTIONS] # Generates a Gemfile into the current working directory bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile bundle install PLUGINS # Install the plugin from the source bundle install [OPTIONS] # Install the current environment to the system bundle issue # Learn how to report an issue in Bundler bundle licenses # Prints the license of all gems in the bundle bundle lock # Creates a lockfile without installing bundle open GEM # Opens the source directory of the given bundled gem bundle outdated GEM [OPTIONS] # list installed gems with newer versions available bundle package [OPTIONS] # Locks and then caches all of the gems into vendor/cache bundle platform [OPTIONS] # Displays platform compatibility information bundle plugin SUBCOMMAND ...ARGS # manage the bundler plugins bundle pristine # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git repository will be issued `git checkout --force`. bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem bundle update [OPTIONS] # update the current environment bundle version # Prints the bundler's version information bundle viz [OPTIONS] # Generates a visual dependency graph Options: [--no-color] # Disable colorization in output -r, [--retry=NUM] # Specify the number of times you wish to attempt network commands -V, [--verbose], [--no-verbose] # Enable verbose output mode ``` ### Why did you choose this fix out of the possible options? I chose this fix because it aligns the Bundler CLI with many other package managers that display a help message of some sort when invoked without arguments: - CocoaPods - npm - RubyGems - Homebrew - pip - Swift Package Manager - Carthage - Cargo And unlike the following, which _do_ install by default: - yarn As to the particular format of the help printed, I thought something concise would be less disruptive than the full man page. Improvements to the output would be welcome, this is just using the Thor default right now but we can easily implement our own. This will require test coverage, but I thought I'd hold off until the general change got some buy-in.
| * | | Default to printing a help message when `bundle` is run without arguments on 2.0seg-default-commandSamuel Giddins2017-06-143-5/+25
| | | |
* | | | Auto merge of #5788 - bundler:seg-allow-bundler-dep-conflicts, r=indirectThe Bundler Bot2017-06-238-10/+64
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [2.0] Allow conflicts between bundler dependencies and the current bundler version ### What was the end-user problem that led to this PR? The problem will occur once 2.0 is released -- there are many gems that declare a `s.dependency "bundler", "~> 1.x"` dependency on bundler. This would essentially make them inoperable with Bundler 2. We want to make adopting 2.0 as pain-free as possible, so hard conflicts are a no-go. ### Was was your diagnosis of the problem? My diagnosis was that we need a way to allow conflicts on the bundler dependency once 2.0 comes out, so people can use 2.0. ### What is your fix for the problem, implemented in this PR? My fix introduces a feature flag for allowing these conflicts (enabled on 2.0), which when enabled will ignore bundler dependencies during resolution, and warn in the installer when a conflict would've occurred. ### Why did you choose this fix out of the possible options? I chose this fix because it has the minimal performance penalty with the feature flag enabled. This is mostly a port of https://github.com/bundler/bundler/pull/3871 to master.
| * | | Make pretty-printing a dependency consistentseg-allow-bundler-dep-conflictsSamuel Giddins2017-06-224-10/+15
| | | |
| * | | Allow conflicts between bundler dependencies and the current bundler versionSamuel Giddins2017-06-226-1/+50
|/ / /
* | | Auto merge of #5805 - bundler:colby/welcome-message, r=colby-swandaleThe Bundler Bot2017-06-221-0/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | 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.
| * | | remove info about running test suite, its redundantcolby/welcome-messageColby Swandale2017-06-221-1/+1
| | | |
| * | | feedback and fixed some clarity issuesColby Swandale2017-06-221-2/+2
| | | |
| * | | add welcome message for PR auto repliesColby Swandale2017-06-221-0/+7
| | | |
* | | | Auto merge of #5804 - bundler:seg-remove-postit-trampoline, r=indirectThe Bundler Bot2017-06-2117-469/+5
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | Completely remove the postit trampolineSamuel Giddins2017-06-2117-469/+5
|/ / / /
* | | | Auto merge of #5802 - koic:remove_require_spec_helper_from_spec_files, ↵The Bundler Bot2017-06-213-3/+0
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | Remove `require "spec_helper"` from spec filesKoichi ITO2017-06-213-3/+0
|/ / / /
* | | | Auto merge of #5795 - bundler:seg-spec-warnings, r=segiddinsThe Bundler Bot2017-06-202-9/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | Avoid warnings in the specs on Ruby 1.8.7seg-spec-warningsSamuel Giddins2017-06-202-9/+2
| | |_|/ | |/| |
* | | | Auto merge of #5791 - bundler:seg-verbose-cli-print-no-defaults, ↵The Bundler Bot2017-06-202-4/+15
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | [CLI] Sort options for stability on ruby < 2seg-verbose-cli-print-no-defaultsSamuel Giddins2017-06-202-2/+2
| | | |
| * | | [CLI] Dont print defaults in the command printed with --verboseSamuel Giddins2017-06-192-4/+15
|/ / /
* | | Auto merge of #5727 - bundler:seg-update-source-feature-flag, r=indirectThe Bundler Bot2017-06-195-1/+23
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Add a feature flag for `bundle update —source NAME` not unlocking a gem ↵seg-update-source-feature-flagSamuel Giddins2017-06-185-1/+23
|/ / | | | | | | with that name
* | Auto merge of #5785 - bundler:colby/fix-group-conflict-error, r=segiddinsThe Bundler Bot2017-06-181-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`
| * | fix a missing space in the group conflict error messagecolby/fix-group-conflict-errorColby Swandale2017-06-181-1/+1
| | |
* | | Auto merge of #5783 - bundler:seg-fix-manpath, r=segiddinsThe Bundler Bot2017-06-172-0/+39
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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.
| * | | [EnvironmentPreserver] Allow preserving MANPATHseg-fix-manpathSamuel Giddins2017-06-162-0/+39
|/ / /
* | | Auto merge of #5729 - HippoDippo:patch-1, r=colby-swandaleThe Bundler Bot2017-06-161-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | Update bundle-gem.ronn Fixed minor typo in Docs. Hope this helps!
View Lorry Controller Status