summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fix a couple of typostyposDavid Rodríguez2019-08-182-2/+2
|
* Merge #7312Bundlerbot2019-08-185-13/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 7312: Remove old rubies stuff no longer needed r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that was still some code specific to old rubies we no longer support. ### What is your fix for the problem, implemented in this PR? My fix is to remove that code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove the :ruby exclusion tagremove_old_rubies_thingsDavid Rodríguez2019-08-181-1/+0
| | | | | | | | | | Our current set of specs is the same for all supported rubies, and we should keep it that way.
| * Remove another 1.8.7 specific bitDavid Rodríguez2019-08-181-5/+0
| |
| * Remove old rubies stuff no longer neededDavid Rodríguez2019-08-183-7/+3
| |
* | Merge #7274Bundlerbot2019-08-1821-104/+86
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7274: Fix more leaks to default copy of bundler r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that in some places, it was still possible to end up requiring files in a different copy of bundler (the default copy). I noticed this when I removed a rubygems monkeypatch from the test suite that was preventing the default copy of bundler from being activated when requiring files. This thing: https://github.com/bundler/bundler/blob/e1c518363641208429f397170354054b3d28effd/spec/support/hax.rb#L15-L20 ### What was your diagnosis of the problem? My diagnosis was that I should use relative requires wherever they were missing. ### What is your fix for the problem, implemented in this PR? My fix is to remove the rubygems hack, migrate the rest of the internal requires to be relative, and also introduce some hacks on our specs to make sure we never load the incorrect copy of bundler. I think this PR should fix the issues in https://github.com/rubygems/rubygems/pull/2863. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove unnecessary requirefix_more_leaks_to_default_copy_of_bundlerDavid Rodríguez2019-08-171-1/+0
| | |
| * | No need to activate the `fileutils` default gemDavid Rodríguez2019-08-174-17/+4
| | | | | | | | | | | | | | | The version we're vendoring actually relaxed this restriction back to 2.3.0+, so we can always use the vendored version.
| * | Comment the changes being applied to vendored libDavid Rodríguez2019-08-171-1/+3
| | |
| * | Remove unnecessary rubygems monkeypatchDavid Rodríguez2019-08-1711-48/+48
| | | | | | | | | | | | | | | Instead, make sure we always load the local copy of bundler during specs, and never end up using the default copy.
| * | Don't use system bundler on this specDavid Rodríguez2019-08-171-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we use system bundler, when booting the "outermost" bundler process, bundler will save the path to the system bundler in BUNDLE_BIN_PATH, and use it again when booting the "innermost" bundler process (`bundle exec echo foo`). That means that second process will use the system bundler path again. However, we have `-rsupport/hax` in RUBYOPT, so that file will load from the local copy of bundler, and that file will load `bundler/version` from the project (not from system), because -Ilib is in the LOAD_PATH. That will end up causing redefinition errors because the same constant will be loaded from two different locations. In general, this is expected behavior, normally you will wrap the process with `Bundler.with_original_env` to reset the environment. However, the easiest fix here is to not use system bundler, because it's not really necessary and thus doesn't help the readability of the spec.
| * | Fix spec using the deprecated `bundle config` modeDavid Rodríguez2019-08-171-1/+1
| | |
| * | Require relatively from exe/ when possibleDavid Rodríguez2019-08-171-3/+19
| | |
| * | Last relative requiresDavid Rodríguez2019-08-173-9/+9
| | |
| * | Remove a bunch of unneeded rubygems requiresDavid Rodríguez2019-08-173-20/+0
| |/
* | Merge #7302Bundlerbot2019-08-172-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7302: Bundler displays a duplicate gem entries warning even if gems only appear once per group r=hsbt a=davidstosik ### What was the end-user problem that led to this PR? I have a Gemfile where some gems appear in two distinct groups. When I run Bundle, the following warning is displayed: > Your Gemfile lists the gem #{gem} more than once. > You should probably keep only one of them. > Remove any duplicate entries and specify the gem **only once (per group)**. > While it's not a problem now, it could cause errors if you change the version of one of them later. Example Gemfile: ```rb source "https://rubygems.org" group :production do end group :development do gem "rake" end group :ci, optional: true do gem "rake" end ``` ### What was your diagnosis of the problem? I think the message is misleading, because it shows even if all gems are specified **only once per group**. ### What is your fix for the problem, implemented in this PR? I removed the _(per group)_ mention from the warning message in order to prevent confusion. ### Why did you choose this fix out of the possible options? I chose this fix because it was the simplest way to bring your attention to the problem. If Bundler's real intent is to allow the same gem to appear in multiple groups, as long as it does not appear more than once per group, then my suggestion is wrong, and instead, the logic around the warning message needs to be fixed. Co-authored-by: David Stosik <david.stosik+git-noreply@gmail.com>
| * | Bundler displays a duplicate gem entries warning even if gems only appear ↵David Stosik2019-08-152-3/+3
| | | | | | | | | | | | once per group
* | | Merge #7309Bundlerbot2019-08-172-3/+9
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7309: Fix `bundle doctor` command r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundle doctor` crashes on very simple usages, like this: ```` $ bundle doctor The Gemfile's dependencies are satisfied --- ERROR REPORT TEMPLATE ------------------------------------------------------- # Error Report ## Questions Please fill out answers to these questions, it'll help us figure out why things are going wrong. - **What did you do?** I ran the command `/home/deivid/.rbenv/versions/2.6.3/bin/bundle doctor` - **What did you expect to happen?** I expected Bundler to... - **What happened instead?** Instead, what happened was... - **Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?** I tried... - **Have you read our issues document, https://github.com/bundler/bundler/blob/master/doc/contributing/ISSUES.md?** ... ## Backtrace ``` Errno::ENOENT: No such file or directory - /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0/bundler /home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `block in find' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `collect!' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `find' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:105:in `each' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:105:in `check_home_permissions' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:83:in `run' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:652:in `doctor' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:26:in `dispatch' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:17:in `start' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:30:in `block in <top (required)>' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors' /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:22:in `<top (required)>' /home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `load' /home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `<main>' ``` ## Environment ``` Bundler 2.1.0.pre.1 Platforms ruby, x86_64-linux Ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux] Full Path /home/deivid/.rbenv/versions/2.6.3/bin/ruby Config Dir /home/deivid/.rbenv/versions/2.6.3/etc RubyGems 3.1.0.pre1 Gem Home /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0 Gem Path /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0 User Home /home/deivid User Path /home/deivid/.gem/ruby/2.6.0 Bin Dir /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0/bin Tools Git 2.22.1 RVM not installed rbenv rbenv 1.1.2 chruby not installed ``` ## Bundler Build Metadata ``` Built At 2019-08-15 Git SHA 91f91a1ad Released Version false ``` ## Bundler settings ``` gem.test Set for the current user (/home/deivid/.bundle/config): "rspec" gem.mit Set for the current user (/home/deivid/.bundle/config): true gem.coc Set for the current user (/home/deivid/.bundle/config): true default_cli_command Set for the current user (/home/deivid/.bundle/config): "install" path_relative_to_cwd Set for the current user (/home/deivid/.bundle/config): true path Set for your local app (/home/deivid/Code/playground/bundler/chcek/.bundle/config): ".bundle" ``` ## Gemfile ### Gemfile ```ruby source "https://rubygems.org" gem "rake", "12.3.2" gem "byebug", "~> 11.0" ``` ### Gemfile.lock ``` GEM remote: https://rubygems.org/ specs: byebug (11.0.1) rake (12.3.2) PLATFORMS ruby DEPENDENCIES byebug (~> 11.0) rake (= 12.3.2) BUNDLED WITH 2.1.0.pre.1 ``` --- TEMPLATE END ---------------------------------------------------------------- Unfortunately, an unexpected error occurred, and Bundler cannot continue. First, try this link to see if there are any existing issue reports for this error: https://github.com/bundler/bundler/search?q=No+such+file+or+directory+-+%2Fhome%2Fdeivid%2FCode%2Fplayground%2Fbundler%2Fchcek%2F.bundle%2Fruby%2F2.6.0%2Fbundler&type=Issues If there aren't any reports for this error yet, please create copy and paste the report template above into a new issue. Don't forget to anonymize any private data! The new issue form is located at: https://github.com/bundler/bundler/issues/new ```` ### What was your diagnosis of the problem? My diagnosis was that `Bundler.home` is not the folder this command should use, because that folder is in reality the "home" for git gems and bundler plugins, not the home for the whole bundle. So it sometimes doesn't exist and the command crashes. ### What is your fix for the problem, implemented in this PR? My fix is to use the proper "home". ### Why did you choose this fix out of the possible options? I chose this fix because it's better than rescuing the error. It was an unexpected error, so we should fix it. Fixes #6820 Closes #6824. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Fix `bundle doctor` commandfix_bundle_doctorDavid Rodríguez2019-08-162-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously `bundle doctor` would fail on any bundle that does not include git gems or plugins. This is because the previously used `Bundler.home` does not exist unless the bundle includes git gems or plugins. For example, with `bundle config set path .bundle`, it points to which does not exist unless this kind of gems exist in the Gemfile. The name `Bundler.home` is really unfortunate, it should probably be have more descriptive name, and be private. But for now I just want to make `bundle doctor` usable.
* | | | Merge #7311Bundlerbot2019-08-172-5/+5
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7311: Use the latest rubygems 3.0.6 in CI r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that [rubygems 3.0.6 was released](https://blog.rubygems.org/2019/08/16/3.0.6-released.html), and we haven't yet tested against it. ### What is your fix for the problem, implemented in this PR? My fix is to use the new rubygems in CI. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Use the latest rubygems 3.0.6 in CIbump_rubygemsDavid Rodríguez2019-08-172-5/+5
| | |_|/ | |/| |
* | | | Merge #7288Bundlerbot2019-08-162-74/+93
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7288: Give a more clear error when user tries to `bundle open` a default gem r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundle open` doesn't currently support opening default gems, but crashes with a very verbose and unclear error when the user tries to do it. ### What was your diagnosis of the problem? My diagnosis was that we should give a more clear error in this case. ### What is your fix for the problem, implemented in this PR? My fix is a rebased and improved version of #4882, that detects the situation and gives a better error. ### Why did you choose this fix out of the possible options? I chose this fix because it was already created and it's simpler than adding support for opening default gems, which is more problematic because they can't be pristine'd easily if edited and might not be in a writable location. Closes #4882. Fixes #4436. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> Co-authored-by: Zehan Zhao <cnallenzhao@gmail.com>
| * | | Move local variable to only branch where it's usedissue-4436David Rodríguez2019-08-161-1/+1
| | | |
| * | | Fix open default gem errorZehan Zhao2019-08-162-5/+22
| | | |
| * | | Wrap `open` specs with a contextDavid Rodríguez2019-08-161-69/+71
| | | | | | | | | | | | | | | | So I can add another context that doesn't run the `before` block.
| * | | Prefer `before` to `before :each`David Rodríguez2019-08-161-1/+1
|/ / /
* | | Merge #7303Bundlerbot2019-08-1611-111/+87
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7303: Refactor ruby core integration r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that sometimes we break specs when integrating bundler changes into core. ### What was your diagnosis of the problem? My diagnosis was that sometimes we use paths dependent on the structure of this repo, but that break under ruby-core's structure. ### What is your fix for the problem, implemented in this PR? My fix is only some refactoring so that usage of structure independent helpers is encouraged. After this set of changes, if you grep the repo for `ruby_core?`, the only result will be `spec/support/path.rb`. That means that all logic dealing with repo folder structure lives in a single place. ### Why did you choose this fix out of the possible options? I chose this fix because it makes the integration in core cleaner. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Extract a `gemspec_dir` helperrefactor_ruby_core_integrationDavid Rodríguez2019-08-162-2/+5
| | |
| * | Extract yet another helper methodDavid Rodríguez2019-08-162-20/+19
| | |
| * | Extract a `root_gemspec` local variableDavid Rodríguez2019-08-161-3/+4
| | |
| * | Extract a `with_root_gemspec` helperDavid Rodríguez2019-08-163-14/+14
| | |
| * | Only chdir when necessaryDavid Rodríguez2019-08-161-16/+14
| | |
| * | Make sure gem has been built before deleteng itDavid Rodríguez2019-08-161-11/+13
| | |
| * | Cleanup in a location independent wayDavid Rodríguez2019-08-161-1/+1
| | |
| * | Remove obvious commentDavid Rodríguez2019-08-161-1/+0
| | |
| * | Remve another unneeded `to_s`David Rodríguez2019-08-161-1/+1
| | | | | | | | | | | | `FileUtils.rm` supports a `Pathname` argument.
| * | Remove unneeded `to_s` callsDavid Rodríguez2019-08-162-3/+3
| | | | | | | | | | | | They are implicit inside `gem_command!`.
| * | Consistently use `Path` over `Spec::Path`David Rodríguez2019-08-161-1/+1
| | |
| * | Extract single gem installation logicDavid Rodríguez2019-08-161-3/+7
| | |
| * | Unalias `install_gem`David Rodríguez2019-08-162-3/+1
| | | | | | | | | | | | Since I plan to reuse it for something else.
| * | Use `join` consistentlyDavid Rodríguez2019-08-161-1/+1
| | |
| * | Extract a `lib_tracked_files` path helperDavid Rodríguez2019-08-162-4/+4
| | |
| * | Rename a variableDavid Rodríguez2019-08-161-4/+4
| | | | | | | | | | | | Otherwise I get conflicts when extracting the helper.
| * | Extract a `tracked_files` path helperDavid Rodríguez2019-08-162-4/+4
| | |
| * | Rename some variablesDavid Rodríguez2019-08-161-19/+19
| | | | | | | | | | | | | | | | | | I want to extract these to path helper methods, but the name `files` conflict with some builder methods that are also available at the same level.
| * | Reconcile testDavid Rodríguez2019-08-161-3/+1
| | | | | | | | | | | | The `:bundler` gem is not needed in the regular repo either.
| * | Reuse `gem_bin` helper inside `gem_command`David Rodríguez2019-08-161-2/+1
| | | | | | | | | | | | | | | The logic for choosing `gem_bin` should work here too even if it's not identical.
| * | Always use `--backtrace` when invoking `gem` CLIDavid Rodríguez2019-08-161-1/+1
| | | | | | | | | | | | For debuggability.
| * | Extract a `gem_bin` path helperDavid Rodríguez2019-08-162-1/+5
| | |
| * | Reuse `gem_command!` helperDavid Rodríguez2019-08-161-8/+4
| | |