summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Enable `Style/UnneededInterpolation` copenable_unneeded_interpolation_copDavid Rodríguez2019-07-2310-20/+23
|
* Merge #7238Bundlerbot2019-07-231-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7238: Point to CoC which contains the contributor covenant r=deivid-rodriguez a=ajwann ### What was the end-user problem that led to this PR? The generated README contains two different links to contributor covenant. Since the generated Code of Conduct *contains* the text of the Contributor Covenant, we can just point the generated README to the generated CoC, and explicitly refer to it as the code of conduct. ### What is your fix for the problem, implemented in this PR? The generated readme now points to the gems CoC (which contains the Contributor Covenant) Closes #6905. Co-authored-by: Adam Wanninger <ajwann@ajwann.com>
| * Point to CoC which contains the contributor covenantAdam Wanninger2019-07-231-1/+2
| |
* | Merge #7255Bundlerbot2019-07-233-7/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7255: Improve environment backup and restore r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the specs were removing some environment variables for every tests, but not all of them, causing problems on some environments (see #7251). ### What was your diagnosis of the problem? My diagnosis was that we don't really need to do this. ### What is your fix for the problem, implemented in this PR? My fix is to stop doing it, and fix the very few specs that failed after the change. One of the failures actually led to a bug fix (I think), see 6c27ebb. ### Why did you choose this fix out of the possible options? I chose this fix because I think it's cleaner than adding a public constant in `lib/` only to fix a problem with the specs, like it's done in #7251. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Add a comment to explain the initial resetimprove_env_backupDavid Rodríguez2019-07-231-0/+1
| |
| * Move environment reset to the only test needing itDavid Rodríguez2019-07-232-2/+4
| |
| * Remove uneeded bundler keyDavid Rodríguez2019-07-231-1/+0
| | | | | | | | | | | | | | It sounds like this was mistankenly added in 4337a499d0108fc3748084934aaed7591b355a26. Then the forgotten MANPATH key was added in bf5bf106230772934602768bb31a68dc925691f0, but this one should've been removed I think.
| * Improve test to make it more independent from envDavid Rodríguez2019-07-231-2/+3
| |
| * Remove unnecessary assignmentsDavid Rodríguez2019-07-231-2/+2
|/
* Merge #7250Bundlerbot2019-07-222-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7250: Fix ruby core dsl spec.rb failure, warning on build_metadata.rb r=deivid-rodriguez a=MSP-Greg ### What was the end-user problem that led to this PR? Travis CI job on Ruby master was failing & had a nuisance warning. ### What is your fix for the problem, implemented in this PR? 1. dls_spec.rb - Minor change to the error msg regexp match string 2. build_metadata.rb - change `if @git_commit_sha` to `if instance_variable_defined? :@git_commit_sha` Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
| * build_metadata.rb - fix 'warning: instance variable @git_commit_sha not ↵MSP-Greg2019-07-161-1/+1
| | | | | | | | initialized'
| * dsl_spec.rb - fix for Ruby coreMSP-Greg2019-07-161-1/+1
| |
* | Merge #7252Bundlerbot2019-07-211-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7252: spec/bundler/shared_helpers_spec.rb - fixup after 7248 r=hsbt a=MSP-Greg PR 7248 https://github.com/bundler/bundler/commit/3f57b102c76fea2f701152e087c88f53df17d3d0 incorrectly changed a path calculation. This reverts. This only affects testing when `ruby_core?` is true. After running Azure Pipelines CI in my ruby/ruby fork and checking the 'bundler' jobs, the error was apparent... Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
| * | spec/bundler/shared_helpers_spec.rb - fixup after 7248MSP-Greg2019-07-201-1/+1
|/ / | | | | | | | | | | PR 7248 incorrectly changed a path calculation. This reverts. After running Azure Pipelines CI in my ruby/ruby fork and checking the 'bundler' jobs, the error was apparent...
* | Merge #7249Bundlerbot2019-07-207-72/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7249: Add `bundle package` functionality to `bundle cache` r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the previous plan provided no migration path from the current `bundle cache` to the future one (an alias to `bundle package`). ### What was your diagnosis of the problem? My diagnosis was that we should probably tell users first that in bundler 3, `bundle cache` will have a different implementation. However, after playing around with it a bit, I noticed that the additions to `bundle cache` provided by `bundle package` are fully backwards compatible. Or maybe I'm missing something but at least all `bundle cache` tests still pass when changing the implementation under the hood to use `bundle package`. As far as I can see, the only backwards incompatible change (start caching `git` and `path` gems by default) is already covered by the exisiting `cache_all` flag), so we should be good. ### What is your fix for the problem, implemented in this PR? My fix is to remove the current implementation of `bundle cache`, and replace it with the current implementation of `bundle package`. ### Why did you choose this fix out of the possible options? I chose this fix because it allows us to remove code and it reduces confusion about `bundle cache` vs `bundle package` making them work exactly the same. On a future PR, I plan to clean this up so that everything (docs, code, tests) use `bundle cache`, and `bundle package` is left only as an alias. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Alias `cache` to `package` nowadd_package_functionality_to_cacheDavid Rodríguez2019-07-152-51/+1
| | | | | | | | | | | | | | | | | | | | | The additions of the `package` command are not actually backwards incompatible, so we can do this transition without further care. All existing specs of `bundle cache` pass when using the `bundle package` implementation for it.
| * | Remove `cache_command_is_package` feature flagDavid Rodríguez2019-07-156-16/+4
| | | | | | | | | | | | | | | So that we handle the removal of `bundle cache` just like we'll handle the removal of `bundle show` and `bundle console`.
| * | Always keep `bundle package --all` optionDavid Rodríguez2019-07-151-4/+3
| | | | | | | | | | | | | | | | | | Just change the default. The reason to do this is that the deprecation message talks about the default being changed, not the option being removed.
| * | Fix incorrect flag usageDavid Rodríguez2019-07-151-1/+1
| | |
| * | Remove redundant conditionDavid Rodríguez2019-07-151-4/+2
| | | | | | | | | | | | This is inside a code branch where the condition is already met.
* | | Merge #7248Bundlerbot2019-07-192-4/+12
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7248: Fix nested bundle exec's when bundler is a default gem r=deivid-rodriguez a=MSP-Greg ### What was the end-user problem that led to this PR? The problem was that when bundler is a default gem, nested `bundle exec` commands generate a LoadError. ``` /home/travis/.rvm/rubies/ruby-head/bin/bundle:30:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-head/lib/bin/bundle (LoadError) ``` ### What was your diagnosis of the problem? Not accounting for Bundler being installed as a default gem. When it's a default, the lib and exe folders do not share the same root folder. This was the result of a change in https://github.com/bundler/bundler/commit/e742c3d5f458a4a59cf0eaab2567eca844f956d1 (#7100). ### Repo Example Using Ruby master/trunk/ruby-head (as of https://github.com/ruby/ruby/commit/0c6c937904aafc1809386bd892a2d114d22d01fe), from a folder where `bundle exec` can be ran: ``` bundle exec "bundle exec 'ruby -v'" ``` ### What is your fix for the problem, implemented in this PR? Small adjustment to logic for finding the correct exe/bundle file. ### Why did you choose this fix out of the possible options? I chose this fix because it's similar to previous code. Fixes #7244. Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
| * | fix nested bundle exec's when bundler is a default gemMSP-Greg2019-07-162-4/+12
| |/
* | Merge #7239Bundlerbot2019-07-158-43/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7239: Fully remove compatibility guard r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that this code is untested and never run. ### What was your diagnosis of the problem? My diagnosis was that we can remove it. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I actually intented to remove this in https://github.com/bundler/bundler/pull/6983, but after a discussing it with @simi I decided to keep it (see https://github.com/bundler/bundler/pull/6983#discussion_r259327593). After a second though I think this is safe to remove and that the potential use case (that the latest bundler is allowed to be installed by a really really old rubygems that didn't support ruby version constraints) is not a problem. The `required_ruby_version` constraint landed in [rubygems 0.6, 15 years ago](https://github.com/rubygems/rubygems/commit/240a9d3a3dc7211cad9680ce2579f502e215b519). Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fully remove compatibility guardremove_compatibility_guardDavid Rodríguez2019-07-098-43/+2
| |
* | Merge #7247Bundlerbot2019-07-126-27/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7247: Drop rubygems 2.5.0 and 2.5.1 support r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we have some conditional code in bundler dependent on the rubygems version being used, that could be easily removed if we dropped support for rubygems 2.5.0 and 2.5.1. ### What was your diagnosis of the problem? My diagnosis was that we could drop support for these versions now, to remove all of those conditionals and simplify the integration. ### What is your fix for the problem, implemented in this PR? My fix is to drop support for rubygems 2.5.0 and 2.5.1. ### Why did you choose this fix out of the possible options? I chose this fix because the oldest ruby we currently support, 2.3, ships with rubygems 2.5.2, so it's very unlikely that any user of the next bundler version will be using these old rubygems versions, because they would need to explicitly downgrade rubygems! Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Drop rubygems 2.5.0 and 2.5.1 supportdrop_rubygems_2_5_0_and_2_5_1_supportDavid Rodríguez2019-07-115-26/+8
| | |
| * | Correct a rubygems test filterDavid Rodríguez2019-07-111-1/+1
| | | | | | | | | | | | It seems to pass under rubygems 2.5.2.
| * | Remove unnecessary test filterDavid Rodríguez2019-07-111-1/+1
| | | | | | | | | | | | Since it covers the whole range we support.
* | | Merge #7246Bundlerbot2019-07-112-12/+4
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7246: No need to make gem refresh a noop r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that rubygems/rubygems#2711 fails because the test in bundler that checks that `Gem.refresh` reveals no system gems fails. ### What was your diagnosis of the problem? My diagnosis was that we don't really need to make `Gem.refresh` a noop at all, because we already setup a `post_reset` hook to automatically go back to the set of specs bundler knows about, everytime `Gem::Specification.reset` is called. See https://github.com/bundler/bundler/blob/847db56c6b5d2156d27990d73a9949507693985a/lib/bundler/rubygems_integration.rb#L551-L554. And `Gem::Specification.reset` is what `Gem.refresh` does: https://github.com/rubygems/rubygems/blob/564bb0a5bb310ccceaf6cd6391b3e67e0712edd5/lib/rubygems.rb#L861-L867. ### What is your fix for the problem, implemented in this PR? My fix is to remove the redefinition of `Gem.refresh`. This makes sense to me not only because it's unnecessary, but because the monkeypatch could still be very easily workarounded by calling `Gem::Specification.reset` directly. After undoing the `Gem.refresh` redefinition, I changed the test to still make sure that the (not overriden) `Gem.refresh` still does not change the set of specs bundler knows about. This is a nice simplification, but doesn't really fix the spec for https://github.com/rubygems/rubygems/pull/2711, because after the first call to `Bundler.rubygems.find_name("rack")`, the `@stubs_by_name` array in rubygems gets populated and thus is no longer empty. We can test the same thing without using `@stubs_by_name` under the hood, so I changed the test to do that, so that the rubygems PR is not affected. ### Why did you choose this fix out of the possible options? I chose this fix because it simplifies the integration between bundler & rubygems, and it unblocks https://github.com/rubygems/rubygems/pull/2711. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Change the refresh spec to not use `stubs_for`no_need_to_make_gem_refresh_a_noopDavid Rodríguez2019-07-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We plan to incrementally populate this array in rubygems, so that will break the test because the first time `find_by_name("rack")` is called will make the `rack` gem available in the array. We can test the same thing using some other way, which is more appropriate anyways, because `Bundler.rubygems.find_name` is only used inside `bundler` to look for the `bundler` gem itself whereas `Bundler.rubygems.all_specs` is used in more places.
| * | No need to make `Gem.refresh` a noopDavid Rodríguez2019-07-112-9/+1
|/ / | | | | | | | | | | The rubygems integration sets up a `post_reset` hook that resets the specs back to what bundler knows after `Gem::Specification.reset` is called (which is what `Gem.refresh` calls under the hood).
* | Merge #7215Bundlerbot2019-07-119-52/+52
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7215: Auto multiplatform r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that currently if the gemfile include gems for specific platforms, like the default `gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby] ` Rails uses, bundler will _always_ print a noisy warning, but I don't think users are doing anything wrong, just running `bundle install` on it. Also, unless they run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`, and commit the resulting lockfile, they will continue to get the same warning over and over again. ### What was your diagnosis of the problem? My diagnosis was that the right thing to do is that instead of warning users, bundler does the right thing by default. That is: * Resolve the gemfile and lock it for all platforms present in the Gemfile. * Install gems for the current platform if requested. ### What is your fix for the problem, implemented in this PR? My fix is to do just that. ### Why did you choose this fix out of the possible options? I chose this fix because I think it's better for our users. We currently have a specific setting to avoid this warning, which I guess we added given the complaints. We no longer need that setting, nor the warning, so I removed both. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Use `tap` for `current_platforms`auto_multiplatformDavid Rodríguez2019-07-101-4/+4
| |
| * Remove now unused methodDavid Rodríguez2019-07-101-4/+0
| |
| * Remove now meaningless settingDavid Rodríguez2019-07-103-4/+1
| |
| * Remove now meaningless warningDavid Rodríguez2019-07-102-30/+1
| |
| * Add all platforms to lockfile by defaultDavid Rodríguez2019-07-104-6/+32
| |
| * Refactor some specsDavid Rodríguez2019-07-102-9/+9
| |
| * Extract `expanded_platforms`David Rodríguez2019-07-102-2/+6
| |
| * Extract `current_platforms`David Rodríguez2019-07-101-3/+9
|/
* Merge #7237Bundlerbot2019-07-097-104/+70
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7237: Remove `add_development_dependency` from gemspec r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our development setup is complicated, and that we are using `add_development_dependency` even though in my opinion its usage should be discouraged. ### What was your diagnosis of the problem? My diagnosis was that our development dependencies are split between the gemspec and the `spec/support/rubygems_ext` file. We can simplify this and centralize everything in the support file. ### What is your fix for the problem, implemented in this PR? My fix is to simplify our development setup by moving everything to `spec/support/rubygems_ext`, while also getting rid of `add_development_dependency` in our gemspec. ### Why did you choose this fix out of the possible options? I chose this fix because it simplifies our setup and it further discourages usage of `add_development_dependency` (after #7222). Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove development dependencies from gemspecremove_add_development_dependency_from_gemspecDavid Rodríguez2019-07-086-81/+55
| | | | | | | | And refactor development setup.
| * Remove unnecessary begin-end blockDavid Rodríguez2019-07-081-15/+13
| | | | | | | | And freeze the resulting hash to appease rubocop.
| * Extract a common error messageDavid Rodríguez2019-07-081-4/+6
| |
| * Remove bundle1 binstubDavid Rodríguez2019-07-081-8/+0
| | | | | | | | Since it's no longer useful.
| * Bump rubocop to 0.72.0David Rodríguez2019-07-081-1/+1
|/
* Merge #7224Bundlerbot2019-07-081-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 7224: Remove unnecessary `order_matters` param r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the `find_gemfile` method was receiving an `order_matters` parameter that's no longer used anywhere. ### What is your fix for the problem, implemented in this PR? My fix is to remove the parameter. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove unnecessary `order_matters` paramremove_order_mattersDavid Rodríguez2019-07-041-3/+3
| |
* | Merge #7222Bundlerbot2019-07-063-18/+26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7222: Remove `add_development_dependency` from new gems r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that a lot of gems in the wild use `add_development_dependency` for their development dependencies, but using `Gemfile`'s for that is more useful. ### What was your diagnosis of the problem? My diagnosis was that the current situation is due to the fact that bundler generates a gem skeleton that uses `add_development_dependency` by default. ### What is your fix for the problem, implemented in this PR? My fix is to stop using `add_development_dependency` in generated gems, and instead use the Gemfile. ### Why did you choose this fix out of the possible options? I chose this fix because it encourages better practices. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Not sure how much this buys us, remove itremove_add_development_dependency_from_new_gemsDavid Rodríguez2019-06-261-2/+0
| | |
View Lorry Controller Status