summaryrefslogtreecommitdiff
path: root/lib/bundler
Commit message (Collapse)AuthorAgeFilesLines
* Add `--[no-]git` option to `bundle gem`git_option_to_bundle_gemDavid Rodríguez2019-07-312-1/+2
| | | | | I think using `--no-git` can be useful when creating gems inside monorepos.
* Merge #7123Bundlerbot2019-07-311-77/+77
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7123: Refactors to `bundle outdated` r=deivid-rodriguez a=ryanfox1985 ### What was the end-user problem that led to this PR? Code in `bundle outdated` code be simpler and more readable. ### What is your fix for the problem, implemented in this PR? My fix is to refactor the command. Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Add exclamation mark to methodDavid Rodríguez2019-07-241-2/+2
| | | | | | | | | | | | | | To indicate that it can raise. Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Move `strict` to an attributeDavid Rodríguez2019-07-241-8/+8
| | | | | | | | | | Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Extract some methodsDavid Rodríguez2019-07-241-19/+31
| | | | | | | | | | Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Unfold message to single line for readabilityDavid Rodríguez2019-07-241-2/+1
| |
| * Extract a `print_gems` methodGuillermo Guerrero2019-07-241-16/+13
| |
| * Less complexityGuillermo Guerrero2019-07-241-15/+8
| |
| * Move more locals to attributesDavid Rodríguez2019-07-241-10/+11
| | | | | | | | | | Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Move `any?` logic to the attributeDavid Rodríguez2019-07-241-5/+3
| | | | | | | | | | | | | | | | It's the only usage of the `options_include_groups` attribute and its name suggests a boolean, so it fits better now. Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Move `options_include_groups` to an attributeDavid Rodríguez2019-07-241-5/+5
| | | | | | | | | | Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
* | Merge #7259Bundlerbot2019-07-291-13/+22
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7259: Relax bundler binstub r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the logic to select bundler versions was different when bundler is run from a rubygems binstub that when bundler is run from a bundler binstub. ### What was your diagnosis of the problem? My diagnosis was that we should unify the logic. ### What is your fix for the problem, implemented in this PR? My fix is to use the same logic implemented in the rubygems version finder, namely, only fail if the major version of bundler does not match. ### Why did you choose this fix out of the possible options? I chose this fix because it makes things consistent. Fixes #7243. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Add workaround from old rubygemsrelax_bundler_binstubDavid Rodríguez2019-07-231-1/+9
| | | | | | | | | | | | | | | In these versions, the `approximate_recommendation` method doesn't include the prerelease logic.
| * | Update error messages to be more preciseDavid Rodríguez2019-07-231-1/+1
| | |
| * | Remove unnecessary method parameterDavid Rodríguez2019-07-231-2/+2
| | |
| * | Use a consistent requirement in binstubDavid Rodríguez2019-07-231-9/+12
| | |
| * | Remove redundant begin-end blockDavid Rodríguez2019-07-231-2/+1
| | |
| * | Don't need 1.8 compatibilityDavid Rodríguez2019-07-231-2/+1
| | |
* | | Merge #7258Bundlerbot2019-07-292-4/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7258: Restore the removal of the `--all` flag for `bundle cache` in Bundler 3 r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I accidentally restored this flag on Bundler 3 in #7249, but the plan still is to remove it. ### What was your diagnosis of the problem? My diagnosis was that I need to remove it again. ### What is your fix for the problem, implemented in this PR? My fix is to remove it. ### Why did you choose this fix out of the possible options? I chose this fix because it's the original plan and makes sense. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Prefer feature flag to harcoded checkDavid Rodríguez2019-07-241-1/+1
| | | |
| * | | Restore `cache_all` flag removalDavid Rodríguez2019-07-241-3/+4
| | |/ | |/|
* | | Merge #6809Bundlerbot2019-07-262-3/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6809: Fix using gemspec & force_ruby_platform on windows r=deivid-rodriguez a=segiddins ### What was the end-user problem that led to this PR? The problem was using `gemspec` and `force_ruby_platform` on Windows would lead to gems not being requirable. Fixes #6801. ### What was your diagnosis of the problem? My diagnosis was there was a place where `force_ruby_platform` wasn't being taken into account, namely the query methods on `Bundler.current_ruby` ### What is your fix for the problem, implemented in this PR? My fix was to add a check for the local platform in `current_ruby`, so the `force_ruby_platform` override would be taken into account. ### Why did you choose this fix out of the possible options? I chose this fix because it avoids hard-coding knowledge of the setting in more places. Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | [CurrentRuby] Say we are ruby? when the generic local platform is ↵segiddins/gemspec-force-ruby-platformSamuel Giddins2019-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Gem::Platform::RUBY This allows us to always say we're ruby? when force_ruby_platform is set, and fixes using gemspec & force_ruby_platform on windows.
| * | | [GemHelpers] Remove the special code path for ruby platform being its own ↵Samuel Giddins2019-07-091-3/+1
| | | | | | | | | | | | | | | | generic
* | | | net-http-persistent 3.1.0 has been releasedbump_net_http_persistentDavid Rodríguez2019-07-253-9/+31
| | | |
* | | | Adapt to the way my automatiek patch worksDavid Rodríguez2019-07-241-1/+1
| | | |
* | | | Bump net-http-persistent to 3.0.1David Rodríguez2019-07-2412-440/+811
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Adds an extra artifice task to vendorize new `connection_pool` dependency. * Cherry-pick's needed Windows fix not yet merged into master branch of `net-http-persistent`. * Update bundler usages to be compatible with the new version, and fix unit specs.
* | | Merge #7261Bundlerbot2019-07-243-3/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7261: Enable `Style/UnneededInterpolation` cop r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that sometimes we have some unneeded string interpolations in our code base. ### What was your diagnosis of the problem? My diagnosis was that we could remove them, because interpolating string variables seems weird and redundant. ### What is your fix for the problem, implemented in this PR? My fix is to remove the unnecessary interpolations, and enable the corresponding rubocop cop. ### Why did you choose this fix out of the possible options? I chose this fix because it fixes the current issues and it enforces the style rule from now on. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Enable `Style/UnneededInterpolation` copenable_unneeded_interpolation_copDavid Rodríguez2019-07-233-3/+3
| | | |
* | | | Merge #7226Bundlerbot2019-07-241-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7226: Improve quality specs r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? I'm not really sure of the exact context when I made these changes, but I recall I was getting some invalid encoding errors somehow, and they turned out to be an estraneous `’` quote in one of the documentation files. ### What was your diagnosis of the problem? My diagnosis was that we should not include this character anywhere, but instead use regular quotes. ### What is your fix for the problem, implemented in this PR? My fix is to add a quality spec for this, and while I was at it, I added some improvements to quality specs in general. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Check for straneous quotesimprove_quality_specsDavid Rodríguez2019-07-101-1/+1
| |/ / | | | | | | | | | And use single quotes consistenly.
* | | 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
| | |/ | |/|
* | | 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.
* | Merge #7250Bundlerbot2019-07-221-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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'
* | | Merge #7249Bundlerbot2019-07-205-62/+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-154-6/+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-191-2/+8
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-2/+8
| |/ /
* | | Merge #7239Bundlerbot2019-07-153-13/+0
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-093-13/+0
| |/
* | Merge #7247Bundlerbot2019-07-123-24/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-113-24/+6
| | |
* | | No need to make `Gem.refresh` a noopDavid Rodríguez2019-07-111-8/+0
|/ / | | | | | | | | | | 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).
* | Use `tap` for `current_platforms`auto_multiplatformDavid Rodríguez2019-07-101-4/+4
| |
View Lorry Controller Status