summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* 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
| |
| * Remove unneeded `to_s` callsDavid Rodríguez2019-12-082-2/+2
| |
| * Lazily load uriDavid Rodríguez2019-12-087-9/+5
| |
* | Fix `bundle exec rake install` not workingDavid Rodríguez2019-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These gem task checks for a specific string in the gem subcommand output. However, if we are inside a bundled environment (`bundle exec rake install` instead of `rake install`), the ruby process will require `bundler/setup` first thing, and initialize a silent UI for rubygems. As a result, the output string will be always empty and the condition for success will always fail. So, even if installation succeeded, user will always be notified of a failure like: ``` foo 1.0 built to pkg/foo-1.0.gem. rake aborted! Couldn't install gem, run `gem install /home/deivid/Code/bundler/tmp/1/bundled_app/pkg/foo-1.0.gem' for more detailed output ... ``` So, don't check for a specific string in the output and only rely on the exit status.
* | Extract a `gem_command` methodDavid Rodríguez2019-12-091-5/+7
| | | | | | | | And use it consistently.
* | Name variable consistenlyDavid Rodríguez2019-12-091-4/+4
|/ | | | Like it is named in the other analogous methods.
* Remove unused methodmisc_cleanupDavid Rodríguez2019-12-061-6/+0
|
* Remove unnecessary code copied from rubygemsDavid Rodríguez2019-12-063-45/+1
| | | | | | | I think the comment is misleading and it referred to rubygems, not gemstash, because this code is about the client side of things. If this is correct, we can drop it because we don't support any rubygems version under 2.5.2, and the fix was introduced in rubygems 2.5.
* Remove unnecessary parameter to `fetch_specs`David Rodríguez2019-12-061-6/+4
|
* Vendor latest thor's masterbump_thorDavid Rodríguez2019-12-0610-45/+83
|
* Vendor fileutils 1.4.1fileutils_1_4_1David Rodríguez2019-11-302-8/+3
|
* Merge #7418Bundlerbot2019-11-291-31/+36
|\ | | | | | | | | | | | | | | | | | | 7418: Restore previous BUNDLE_GEMFILE in bundler/inline r=deivid-rodriguez a=fatkodima [Without spacing changes](https://github.com/bundler/bundler/pull/7418/files?w=1) Closes #7159 Co-authored-by: fatkodima <fatkodima123@gmail.com>
| * Restore previous BUNDLE_GEMFILE in bundler/inlinefatkodima2019-11-221-31/+36
| |
* | Lazily load CGIDavid Rodríguez2019-11-271-1/+1
| | | | | | | | | | Since cgi is now a default gem on ruby 2.7, we're getting some unintended activations of the new default gem inside our specs.
* | Merge #7455Bundlerbot2019-11-261-1/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7455: Lazily load `open3` r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was `open3` will be gemified in ruby 2.7, and since we use it inside `bundler`, we might activate a version causing a conflict with the user's choice. ### What was your diagnosis of the problem? My diagnosis was that only loading it when needed should be better. ### What is your fix for the problem, implemented in this PR? My fix is to lazily load it. I expect this PR to fix [some of the errors](https://travis-ci.org/bundler/bundler/jobs/615940817) currently happening in our CI against ruby-head. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Lazily load `open3`David Rodríguez2019-11-261-1/+2
| |/ | | | | | | | | Since it's a default gem now, it's better to load it as late as possible.
* | Add :glob to git source uniquenessfatkodima2019-11-211-3/+4
|/
* Merge #7442Bundlerbot2019-11-211-3/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7442: Fix `bundle exec`'ing to rubygems being silent r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that #7401 caused a regression where `bundle exec`'ing to rubygems would silence rubygems output. ### What was your diagnosis of the problem? My diagnosis was that the removal of: * Code where `Bundler::RGProxy` would be only set conditionally on `Bundler.ui =` not being passed `nil`. * Code setting `Bundler.ui` to `nil` right before shelling during `bundle exec`. caused rubygems UI to be silent during `bundle exec gem`. ### What is your fix for the problem, implemented in this PR? My fix is to explictly "unsilence" rubygems UI before `bundle exec` calls. ### Why did you choose this fix out of the possible options? I chose this fix because it's more explicit than the previous one. Fixes #7441. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix shelling out to rubygems being silentDavid Rodríguez2019-11-181-3/+12
| |
* | Pick up changelog and version bump from 2-1-stableDavid Rodríguez2019-11-181-1/+1
|/
* Pickup latest changes in thor masterDavid Rodríguez2019-11-1118-217/+118
| | | | | | Using `bin/rake vendor:thor[master]`. So that we're ready for an upcoming release.
* Remove unnecessary requireDavid Rodríguez2019-11-111-1/+0
| | | | | I think this comes from times where our vendored `Thor` was not namespaced and we were doing this to avoid conflicts.
* Merge #7423Bundlerbot2019-11-092-4/+9
|\ | | | | | | | | | | | | | | 7423: Ignore local overrides for bundle pristine r=deivid-rodriguez a=fatkodima Closes #6836 Co-authored-by: fatkodima <fatkodima123@gmail.com>
| * Ignore local overrides for bundle pristinefatkodima2019-11-062-4/+9
| |
* | Merge #6455Bundlerbot2019-11-084-4/+24
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6455: [CLI::Gem] Add a --rubocop option r=deivid-rodriguez a=segiddins Based upon #6451. ### What was the end-user problem that led to this PR? The problem was I always have to remember how to add RuboCop to my Rakefile when I set up a new gem. ### What was your diagnosis of the problem? My diagnosis was that RuboCop 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 adds an option to `bundle gem` to add in RuboCop, in the same way options like `:coc`and `:mit` are handled. ### Why did you choose this fix out of the possible options? I chose this fix because it does not require bundler have an opinion on _how_ rubocop is configured. Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
| * | [CLI::Gem] Add a --rubocop optionsegiddins/bundle-gem-rubocop-optionSamuel Giddins2019-10-194-4/+24
| | |
* | | Remove rubygems integration dead codedead_codeDavid Rodríguez2019-11-071-29/+0
| | |
View Lorry Controller Status