summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Add support for BUNDLER_ prefixed debug environment variablesSutou Kouhei2020-01-192-2/+7
| | | | | DEBUG_RESOLVER is used in RubyGems too. So we can't enable it only for Bundler.
* Merge #7577Bundlerbot2020-01-182-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7577: Update references to old repo location r=deivid-rodriguez a=duckinator Related: #7572. ### What was the end-user problem that led to this PR? A lot of things use the outdated `https://github.com/bundler/bundler` URL (and similarly for e.g. `bundler/bundler-site`). ### What is your fix for the problem, implemented in this PR? My fix was to update the outdated URLs. :slightly_smiling_face: ### TODO - [x] `bundler.gemspec` - [x] `CHANGELOG.md` (Moved to its own PR, #7582) - [x] `CODE_OF_CONDUCT.md` - [x] `doc/`, excluding reference to now-dead `pullreview.com` - [x] `doc/contributing/HOW_YOU_CAN_HELP.md` reference to long-dead `pullreview.com` - [x] `.github/config.yml` - [x] `lib/` (comments) - [ ] `lib/` (functional changes) - [ ] `man/` - [x] `README.md` - [x] `spec/` (comments, `skip` messages) - [ ] `spec/` (functional changes) - [ ] `task/release.rake` Co-authored-by: Ellen Marie Dash <me@duckie.co>
| * [repo move] Update GitHub URL in comments in lib/.Ellen Marie Dash2020-01-162-2/+2
| |
* | Merge #7559Bundlerbot2020-01-171-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7559: Reactivate usused code for ruby version resolution r=deivid-rodriguez a=larskanis The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly. ### What was the end-user problem that led to this PR? Not known. ### What was your diagnosis of the problem? I read the bundler source code and noticed this. ### What is your fix for the problem, implemented in this PR? My fix re-adds the ruby version as it was before commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 , since it seems to be a mistake. ### Why did you choose this fix out of the possible options? As a alternative I added #7558 that removes the code in question. Co-authored-by: Lars Kanis <kanis@comcard.de>
| * | Reactivate usused code for ruby version resolutionLars Kanis2020-01-161-2/+2
| |/ | | | | | | | | The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly.
* | Revert MatchPlatform#platforms_match?Sutou Kouhei2020-01-171-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because some examples are failed: rspec ./spec/cache/gems_spec.rb:236 # bundle cache when previously cached doesn't remove gems that are for another platform rspec ./spec/commands/install_spec.rb:220 # bundle install with gem sources the simple case with a gem that installs multiple platforms installs gems for the local platform as first choice rspec ./spec/commands/update_spec.rb:39 # bundle update with --all updates the entire bundle rspec ./spec/commands/update_spec.rb:49 # bundle update with --all doesn't delete the Gemfile.lock file if something goes wrong rspec ./spec/commands/update_spec.rb:104 # bundle update with a top level dependency unlocks all child dependencies that are unrelated to other locked dependencies rspec ./spec/commands/update_spec.rb:115 # bundle update with an unknown dependency should inform the user rspec ./spec/commands/update_spec.rb:119 # bundle update with an unknown dependency should suggest alternatives rspec ./spec/commands/update_spec.rb:126 # bundle update with a child dependency should update the child dependency rspec ./spec/commands/update_spec.rb:299 # bundle update in a frozen bundle should suggest different command when frozen is set globally rspec ./spec/runtime/platform_spec.rb:60 # Bundler.setup with multi platform stuff will add the resolve for the current platform
* | Don't ignore resolved platform informationSutou Kouhei2020-01-172-3/+11
|/ | | | This is a follow-up change of #7522.
* Remove needless ifSutou Kouhei2020-01-161-4/+5
|
* Sort available platformsSutou Kouhei2020-01-151-7/+8
|
* Always add a spec group for all platforms to candidatesSutou Kouhei2020-01-151-26/+11
|
* SpecGroup#to_specs doesn't return duplicated specsSutou Kouhei2020-01-152-1/+9
|
* Fix styleSutou Kouhei2020-01-151-2/+2
|
* Always add "ruby" version to selected spec groups as fallbackSutou Kouhei2020-01-151-3/+5
|
* Rename SpecGroup#spec to SpecGroup#spec_forSutou Kouhei2020-01-152-4/+5
|
* Add SpecGroup#copy_forSutou Kouhei2020-01-152-12/+12
|
* Add support for force_ruby_platform with specific_platform againSutou Kouhei2020-01-151-5/+16
|
* Don't set platforms to dependency registered by gemspecSutou Kouhei2020-01-153-14/+1
| | | | | | | | | Platform related dependencies are resolved in Resolver now. So we don't need to register all available platforms explicitly. This reverts commit 0a8ca4879e0b79aa4109a0dc424940b079ef38d0. See also: #4150 and #4102
* Add support for specific_platform feature flagSutou Kouhei2020-01-151-5/+10
|
* Add support for multiple platform spec group againSutou Kouhei2020-01-152-4/+31
|
* Improve platform specific gem resolutionSutou Kouhei2020-01-152-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | It resolves #6247. This changes includes the patches that add (RSpec) specs for this situation in #6247. If there is a platform specific gem but it can't be resolved available version, Bundler reports an error. For example, @index = build_index do gem "bar", "1.0.0" gem "foo", "1.0.0" gem "foo", "1.0.0", "x64-mingw32" do dep "bar", "< 1" end end dep "foo" platforms "x64-mingw32" raises an error because foo-1.0.0-x64-mingw32 requires bar<1 but there isn't bar<1. With this change, foo-1.0.0 (no x64-mingw32) is used as fallback. Because foo-1.0.0 doesn't depend on bar<1.
* Fix instance variable nameSutou Kouhei2020-01-121-2/+2
|
* Fix ruby version parsing in compact indexSutou Kouhei2020-01-122-13/+71
| | | | | We can't use the same logic as "dependencies" for "requirements". Because "," in "requirements" isn't escaped as "&".
* Merge #5521Bundlerbot2020-01-087-11/+36
|\ | | | | | | | | | | | | | | 5521: bundler gem: Support test-unit as a testing framework r=hsbt a=kou Co-authored-by: Kouhei Sutou <kou@clear-code.com>
| * bundler gem: Support test-unit as a testing frameworkKouhei Sutou2019-12-117-11/+36
| |
* | Merge #7529Bundlerbot2020-01-051-22/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7529: Remove optional require net-http-pipeline from vendored net-http-persistent. r=deivid-rodriguez a=marciotoshio ### What was the end-user problem that led to this PR? See issue https://github.com/bundler/bundler/issues/7521. ### What was your diagnosis of the problem? My diagnosis was If you have net-http-pipeline gem installed bundler loads it and you can't vendor it. ### What is your fix for the problem, implemented in this PR? My fix is remove the optional require of net-http-pipeline. ### Why did you choose this fix out of the possible options? I chose this fix because was a recommendation in the issue by @deivid-rodriguez Fixes #7521. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> Co-authored-by: Marcio Toshio <marcio@tosh.io>
| * | Remove require net-http-pipeline from vendored net-http-persistent.Marcio Toshio2020-01-031-22/+0
| | |
* | | Reset `Gemfile` to the empty string after bundler/inlinefix/bundler_inlineDavid Rodríguez2020-01-021-1/+1
|/ / | | | | | | | | To avoid Gemfile resolution afterwards, and use the "inline environment" instead.
* | Set master's version to 2.2.0.devbump_master_versionDavid Rodríguez2020-01-011-1/+1
| | | | | | | | | | | | | | So that it's always higher than the latest patch level release. This saves us from having to merge back the version bump after each patch level release, which is also not accurate since master is "bigger" than the latest patch level release anyways.
* | Unify deployment setting and flagimprove_deployment_flagDavid Rodríguez2019-12-311-2/+3
| | | | | | | | | | | | Previously, we were recommending `bundle config deployment true; bundle install` as an alternative to `bundle install --deployment`, but they were not working equally.
* | Do `require "rubygems"` only when neededYusuke Endoh2019-12-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This require causes circular require. ``` $ touch empty_file $ RUBYGEMS_GEMDEPS=empty_file ./local/bin/ruby -w -e '' /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92: warning: /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92: warning: loading in progress, circular require considered harmful - /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems.rb from <internal:gem_prelude>:1:in `<internal:gem_prelude>' from <internal:gem_prelude>:1:in `require' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems.rb:1417:in `<top (required)>' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems.rb:1203:in `use_gemdeps' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/user_interaction.rb:47:in `use_ui' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems.rb:1204:in `block in use_gemdeps' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' from /home/mame/work/ruby/local/lib/ruby/2.7.0/bundler.rb:11:in `<top (required)>' from /home/mame/work/ruby/local/lib/ruby/2.7.0/bundler.rb:11:in `require_relative' from /home/mame/work/ruby/local/lib/ruby/2.7.0/bundler/rubygems_integration.rb:3:in `<top (required)>' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' from /home/mame/work/ruby/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' ```
* | Merge #7510Bundlerbot2019-12-231-2/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7510: Don't spawn a shell when git pushing on release r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I almost went crazy when trying to release the last bundler version. `rake release` was hanging and I didn't know why. ### What was your diagnosis of the problem? Thanks to passing `DEBUG=true` to the task, I noticed that it was `git push` and `git push --tags` commands that were hanging: ``` $ DEBUG=true bin/rake release ["gem", "build", "-V", "/home/deivid/Code/bundler/bundler.gemspec"] bundler 2.1.2 built to pkg/bundler-2.1.2.gem. ["git", "diff", "--exit-code"] ["git", "diff-index", "--quiet", "--cached", "HEAD"] ["git", "tag"] ["git", "tag", "-m", "Version 2.1.2", "v2.1.2"] Tagged v2.1.2. git push git push --tags ^Crake aborted! Interrupt: /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:198:in `read' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:198:in `popen' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:198:in `block in sh_with_status' /home/deivid/Code/bundler/lib/bundler/shared_helpers.rb:52:in `chdir' /home/deivid/Code/bundler/lib/bundler/shared_helpers.rb:52:in `block in chdir' /home/deivid/Code/bundler/lib/bundler/shared_helpers.rb:51:in `chdir' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:197:in `sh_with_status' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:133:in `perform_git_push' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:115:in `git_push' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:64:in `block (2 levels) in install' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:160:in `tag_version' /home/deivid/Code/bundler/lib/bundler/gem_helper.rb:64:in `block in install' /home/deivid/Code/bundler/Rakefile:14:in `block in invoke' /home/deivid/Code/bundler/Rakefile:13:in `invoke' /home/deivid/Code/bundler/spec/support/rubygems_ext.rb:87:in `load' /home/deivid/Code/bundler/spec/support/rubygems_ext.rb:87:in `gem_load_and_activate' /home/deivid/Code/bundler/spec/support/rubygems_ext.rb:45:in `gem_load' Tasks: TOP => release => release:source_control_push (See full trace by running task with --trace) ``` The debugging output is very interesting because it also tells us that these commands are the only ones passing Strings to `IO.popen` instead of Arrays. That means these commands are [spawning a new shell](https://ruby-doc.org/core-2.6.5/IO.html#method-c-popen). That's when I realized that I have [hub](https://github.com/github/hub) installed on my system and `git` aliased to it. So I figure this aliasing was interacting with the subcommand in a bad way. Indeed, disabling `hub` fixed the issue and let me make the release. ### What is your fix for the problem, implemented in this PR? I think we can avoid other issues similar to this for people pushing releases by not spawing a shell here, just like we do with all of the other commands. I think it's a good practice anyways. ### Why did you choose this fix out of the possible options? I chose this fix because I think it makes the code better. Of course I can disable `hub` every time I release, but I think this is worth doing. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | `cmd` is a String, we don't shelljoin thatdont_spawn_a_shell_when_git_pushing_on_releaseDavid Rodríguez2019-12-201-1/+0
| | |
| * | Don't spawn a new shell on `git push` when releasingDavid Rodríguez2019-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | These `git push` operations are the only ones passing a string argument to `IO.popen` and those are the exact commands hanging for me when I try to release. I'm not sure what the reason is (maybe that I use hub, which does some fancy shell aliasing?), but I think it's a good practice to avoid a new shell anyways.
* | | Version 2.1.2David Rodríguez2019-12-221-1/+1
| | |
* | | Merge #7513Bundlerbot2019-12-221-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7513: Improve error message when not logged in r=deivid-rodriguez a=steveklabnik `gem push` makes you add other parameters, and is awkward to figure out the details. `gem signin` is a more direct way of doing this. Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
| * | | Improve error message when not logged inSteve Klabnik2019-12-201-1/+1
| |/ / | | | | | | `gem push` makes you add other parameters, and is awkward to figure out the details. `gem signin` is a more direct way of doing this.
* | | Fix `rake build` when path has spaces on itfix/rake_build_with_spaced_pathDavid Rodríguez2019-12-201-1/+1
|/ /
* | Make sure to `require "rubygems"` explicitlyrequire_rubygemsDavid Rodríguez2019-12-181-0/+2
| | | | | | | | | | | | Some setups have `--disable=gems` in `RUBYOPT`, and sometimes use `bundler` without modifying that env. Let's not break those setups just to save a `require`.
* | Version 2.1.1David Rodríguez2019-12-181-1/+1
| |
* | Merge #7498Bundlerbot2019-12-171-0/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7498: Add compatibility methods for `rubygems-bundler` gem r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundler install` on a `ruby` installation using `rvm` is broken by default. ### What was your diagnosis of the problem? My diagnosis was that during 2.1.0 development phase I removed some stuff I thought it was internal and nobody would be using. ### What is your fix for the problem, implemented in this PR? My fix is to restore a minimal compatibility layer so that this stuff works again. ### Why did you choose this fix out of the possible options? I chose this fix because I think this is the minimum set of additions that gets stuff working again. Fixes #7488. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Add compatibility methods for `rubygems-bundler` gemfix_rubygems_bundler_integrationDavid Rodríguez2019-12-171-0/+8
| | | | | | | | | | | | | | | Hopefully `rvm` won't install this gem by default, but for now I'm adding the following two methods for compatibility with it.
* | | Merge changelog and version bump back to masterDavid Rodríguez2019-12-171-1/+1
|/ /
* | Fix another silent rubygems issuefix_another_silent_rubygems_issueDavid Rodríguez2019-12-162-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We might be shelling out to rubygems in a `bundle exec` context. In the case where we don't shell out to the `gem` binstub directly, the previous trick wouldn't work. Instead, reset the rubygems ui right after `bundler/setup`, so that if we end up shelling out to rubygems, it will use its default shell (non-silent). The best place to fix this would probably be right inside the `gem` script, but even if we fix it there, we'll need workarounds for previous rubygems versions inside `bundler` so I think this is good for now.
* | Vendor thor 1.0.0David Rodríguez2019-12-143-9/+44
| |
* | Delay deprecation of `bundle config` and `bundle update` without argsundeprecate_argless_config_and_updateDavid Rodríguez2019-12-133-3/+3
| |
* | Merge #7460Bundlerbot2019-12-1329-55/+4201
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7460: Vendor `uri` library r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that after the gemification of the `uri` library (which will happen in ruby 2.7), `bundler` will activate the default version of the new library inside its own `bundler/setup` code. That means users won't be able to specify the version of the library they want/need to use in their own Gemfiles. ### What was your diagnosis of the problem? My diagnosis was that we should avoid using `uri` inside `bundler/setup` code. ### What is your fix for the problem, implemented in this PR? My fix is to vendor the `uri` library, like we did with `fileutils`. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Use vendorized version of uri libraryDavid Rodríguez2019-12-0812-23/+23
| | |
| * | Vendorize "uri" libraryDavid Rodríguez2019-12-0815-26/+4171
| | | | | | | | | | | | | | | We vendorize it as a dependency of `net-http-persistent`, so usages inside `net-http-persistent` get automatically replaced by `automatiek`.
| * | This `require` seems unneededDavid Rodríguez2019-12-081-1/+0
| | |
| * | Refactor stuff to not load URI if not neededDavid Rodríguez2019-12-082-5/+11
| | |
View Lorry Controller Status