summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Remove unnecessary env variable checkingbundle_env_improvementsDavid Rodríguez2019-04-151-2/+2
| | | | | | Rubygems already sets these paths from the environment, and once they are set, it uses the paths and not the environment. So the check is unnecessary and potentially misleading.
* Add user home to `bundle env`David Rodríguez2019-04-151-0/+1
|
* Merge #7043Bundlerbot2019-04-142-349/+117
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7043: Remove old rubygems compatibility code r=bronzdoc a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I was unsure where I needed to add the compatibility layer to #6963, and it took me a bit to scan through the compatibility file and figure it out. ### What was your diagnosis of the problem? My diagnosis was that all this compatibility code is unused but makes this file harder to understand and scan through. ### 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 chose this fix because we can do it, I think. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove more unnecessary coderemove_old_rubygems_compatibility_codeDavid Rodríguez2019-04-091-2/+0
| | | | | | | | The `full_gem_path` writer has been there since rubygems 2.2
| * Remove unnecessary codeDavid Rodríguez2019-04-091-10/+4
| | | | | | | | The `source` method has been there since rubygems 2.1.
| * Remove unused variableDavid Rodríguez2019-04-091-2/+0
| |
| * Remove more unnecessary logicDavid Rodríguez2019-04-091-8/+3
| |
| * Remove last level of inheritanceDavid Rodríguez2019-04-091-127/+120
| |
| * Remove one level of inheritanceDavid Rodríguez2019-04-091-5/+2
| |
| * Remove more uneeded stuffDavid Rodríguez2019-04-091-62/+0
| |
| * Remove old rubygems compatibility codeDavid Rodríguez2019-04-091-146/+1
| |
* | Merge #6730Bundlerbot2019-04-143-6/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6730: Print errors to stderr by default, and remove configuration option r=greysteil a=greysteil ### What was the end-user problem that led to this PR? The problem was #6729 - Bundler unexpectedly outputs error and warning messages to STDOUT. ### What was your diagnosis of the problem? My diagnosis was that whilst very minorly breaking, this is essentially a bug fix, and should be considered for inclusion for Bundler 2.0 even if very few other breaking changes are. ### What is your fix for the problem, implemented in this PR? My fix was so switch output for warning and error messages to STDERR, and remove the configuration option (as is redundant once the setup is flipped - anyone wanting to redirect those message to STDOUT could do so in their shell). ### Why did you choose this fix out of the possible options? I chose this fix because I think the new behaviour is what everyone would expect, and we should get it out from behind its feature switch sooner rather than later. Alternatively, we might want to keep the Bundler 2.0 release "purer" by only dropping Ruby versions in it - that's totally fine too, but I figured we should have the code to discus #6729, rather than doing it in abstract. Co-authored-by: Grey Baker <greysteil@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Print errors to stderr by default, and remove configuration optionGrey Baker2019-04-123-6/+2
| | |
* | | Another tryDavid Rodríguez2019-04-121-3/+3
| | |
* | | Improve wordingDavid Rodríguez2019-04-121-1/+1
| | |
* | | Add warning about conflicting executablesDavid Rodríguez2019-04-121-8/+14
| | |
* | | Convert binstub conflict deprecation to a warningDavid Rodríguez2019-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And test it. I don't think it makes sense as a deprecation, since nothing is changing, and there's no alternative. This is a potentially undesired situation caused by gems shipping executables conflicting with the executables of other gems. `bundle exec` is fine in general, this is just a potentially undesired situation that can be fixed by using project specific binstubs.
* | | Assume `exec_name` needs to be givenDavid Rodríguez2019-04-121-7/+3
|/ /
* | Merge #7113Bundlerbot2019-04-122-2/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7113: Make `init_gems_rb` a regular setting r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we have a feature flag to change the file name of the file where gems are defined from `Gemfile` to `gems.rb`, and it is unclear whether we will actually do this, and when. ### What was your diagnosis of the problem? My diagnosis was that a feature flag is not a good fit here. It's perfectly fine to configure this and allow users to use `gems.rb` by default for their gems, but we don't know when/if we will actually change the default so a plain setting feels better than a feature flag. ### What is your fix for the problem, implemented in this PR? My fix is to convert the `init_gems_rb` feature flag into a plain setting. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Make `init_gems_rb` a regular settingmake_init_gems_rb_a_settingDavid Rodríguez2019-04-112-2/+1
| | | | | | | | | | | | | | | | | | | | | I think it's nice that users can configure this and start using `gems.rb`. But there's no need to make this a feature flag and change its default value. Let's keep generating Gemfile's by default until we are ready, if we ever are.
* | | Remove `prefer_gems_rb` settinginit_gems_rbDavid Rodríguez2019-04-113-13/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | In my opinion, it's overkill to provide a setting for how little this setting was doing. Both types of Gemfile are supported and work regardless of this setting. The only difference this setting would make is the warning message one would get when having _both_ types of Gemfiles in the same project. I changed things so that gems.rb is always looked up first, and the warning message in case you have both always tells you to remove Gemfile and Gemfile.lock.
* | Move on to bundler 3David Rodríguez2019-04-113-23/+23
| | | | | | | | | | | | * Drop bundler 1 stuff from tests. * Move all feature flags to bundler 3 (like they are in 2-0-stable) and get them tested.
* | Cherry-pick github source removal from Gemfile templateDavid Rodríguez2019-04-111-2/+0
| |
* | Merge #7057Bundlerbot2019-04-118-18/+15
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7057: Review multiple sources deprecation r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I had not yet reviewed the deprecation about multiple global sources being present on a Gemfile, and thus the specs were skipped. ### What was your diagnosis of the problem? My diagnosis was that we need to delay the removal of multiple sources support to bundler 3, so that we can show the deprecations in the 2.x series. I also noticed that part of the deprecation message was inaccurate. In order to upgrade the warning to an error, you would also need to configure the `lockfile_uses_separate_rubygems_sources` setting. Otherwise you will get an error that these two settings depend on each other and can't be enabled separatedly. ### What is your fix for the problem, implemented in this PR? My fix is to delay these feature flags to bundler 3 so that the deprecation specs pass. Also, since before giving this advice I'd like to study why we have two different settings that can't be enabled separately, and why the can't be merged to a single one, I have removed that part of the message for now. ### Why did you choose this fix out of the possible options? I chose this fix because it keeps me moving with reviewing all the deprecations for bundler 3 breaking changes, and makes sure that the deprecations for this change of behavior are tested (and passing). Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Move multiple global source removal to bundler 3David Rodríguez2019-04-081-1/+1
| | | | | | | | And fix specs.
| * Merge multisource related settingsDavid Rodríguez2019-04-088-17/+12
| |
| * Allow running source list specs in isolationDavid Rodríguez2019-04-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Currenty one gets errors like ``` Failure/Error: lock_sources.to_set == replacement_sources.to_set NoMethodError: undefined method `to_set' for #<Array:0x0000560a01cd97c0> Did you mean? to_s ```
* | Remove ruby 1.8 compatibility codecleanup_old_rubies_stuffDavid Rodríguez2019-04-081-5/+2
| | | | | | | | | | | | | | | | The comment about this being for rubygems 1.8 compatibility seems wrong, it was for ruby 1.8 compatibility, as can be seen by these docs: https://ruby-doc.org/core-1.8.7/Module.html#method-i-instance_methods https://ruby-doc.org/core-1.9.3/Module.html#method-i-instance_methods
* | Remove QuickLoader mentionDavid Rodríguez2019-04-081-5/+0
| | | | | | | | No longer provided by ruby since 1.8 times.|
* | Cleanup more stuff only needed for old rubiesDavid Rodríguez2019-04-083-10/+2
| |
* | Remove unused constantDavid Rodríguez2019-04-081-14/+0
| | | | | | | | Stopped being used in 8b749ee85b04307135d368f05275d50e6cbf76a0.
* | Cleanup old stuffDavid Rodríguez2019-04-081-14/+0
|/
* Merge #7038Bundlerbot2019-04-061-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7038: Strip unknown regexp option line from error format r=hsbt a=k0kubun ### What was the end-user problem that led to this PR? On Gemfile syntax error like `gem 'foo', :path => /unquoted/string/syntax/error`, Ruby 2.7 will show strange error message like: ``` [!] There was an error parsing `Gemfile`: unknown regexp options - trg - ...foo', :path => /unquoted/string/syntax/error ... ^~~~~~~. Bundler cannot continue. ``` due to recent change in Ruby trunk https://github.com/ruby/ruby/commit/b6468b01f7288789ef2e9bf548d81cdadb8ef053. This caused Bundler's [CI failure on ruby/ruby repository](https://dev.azure.com/rubylang/ruby/_build/results?buildId=180&view=logs&jobId=b6208202-37e9-506d-3aed-7f8fc7b76c87&taskId=a8620f99-3e9e-5782-41a8-f55e2d53059e&lineStart=94&lineEnd=95&colStart=1&colEnd=1). Bundler's Travis ruby-head has not failed yet because Travis ruby-head is still a little old. It will fail later and this is fixing the future failure. ### What was your diagnosis of the problem? SyntaxError's message was changed to have an additional message indicating a position of an unknown regexp option like: ``` foo /bar/baz ^~~ ``` or ``` ...oooooooooooooooooooooo /bar/baz ... ^~~ ``` ### What is your fix for the problem, implemented in this PR? My fix tries to strip the new message part because the error line is already shown in another part of `DSLError#to_s`. ### Why did you choose this fix out of the possible options? To keep the best compatibility with older Bundler versions. Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
| * Strip unknown regexp option line from error formatTakashi Kokubun2019-03-141-1/+1
| |
* | Typo. s/expect/except/David Rodríguez2019-04-051-1/+1
| |
* | Remove `list_command` settingDavid Rodríguez2019-04-053-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The list command was still present (just aliased to `bundle show`), even if the setting was set to false. So the setting was at least super confusing if not just wrong. It also led to misleading situations such as ``` $ bundle list --help (...) NAME bundle-list - List all the gems in the bundle SYNOPSIS bundle list [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP] (...) $ bundle list --only-group=development Unknown switches '--only-group=development' ``` So, instead, I enable the new list command _always_ and remove the `bundle list => bundle show` alias.
* | Print a better messages on undocumented flagsDavid Rodríguez2019-04-051-8/+12
| | | | | | | | | | Inform about complete removal when `bundle show --outdated` and `bundle show --verbose`.
* | Remove `bundle show` from bundler 3David Rodríguez2019-04-051-27/+28
| |
* | Move `bundle list` addition to bundler 3David Rodríguez2019-04-051-1/+1
| |
* | Remove explictily loading thread library, It's provided by embedded module ↵remove-threadSHIBATA Hiroshi2019-04-052-3/+0
| | | | | | | | in the modern Ruby.
* | Merge #7023Bundlerbot2019-04-041-1/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7023: Shellsplit build config r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was #6940. Build configurations with multiple whitepaced parameter are no longer properly handled. ### What was your diagnosis of the problem? My diagnosis was not mine, was @jeremy's: Since [shellscaping / shelljoining build arguments to the rubygems gem installer](https://github.com/bundler/bundler/issues/6940), these are no longer properly passed ### What is your fix for the problem, implemented in this PR? My fix is not mine, it's @jeremy's: shellsplit settings before passing them. ### Why did you choose this fix out of the possible options? I chose this fix because it works and it sounds like the proper followup to https://github.com/rubygems/rubygems/pull/2441. Fixes #6940. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Shellsplit build configshellsplit_build_configDavid Rodríguez2019-03-281-1/+5
| | |
* | | Merge #7084Bundlerbot2019-04-043-6/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7084: Remove command removal settings r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the `viz_command` and `console_command` settings are not meant to be something configured by users. These commands are going away, we don't want to support optionally keeping them. ### What was your diagnosis of the problem? My diagnosis was that we are using settings for two different things: * Different supported behaviors that are configurable by users. * Feature flags that allow us developers to easily maintain a single branch of code and making breaking changes more easily, and users to opt-in/out of certain new features/changes. The second case is valid but it's complicated because we need to commit to provide a proper life cycle for the setting: * Allow opting in through the setting. * Toggle the setting's default value. * Deprecate the value for the setting enabling the old behavior. * Deprecate the setting altogether making it a no-op. * Finally removing the setting. I plan to work on that, but I didn't start yet. Instead, what we've been doing to workaround this is to try to not expose these settings to users by, for example, not documenting them. However, in my opinion, in this particular case it's best to instead not provide a setting at all, and check for the bundler version directly for whether we should be providing the command. The only extra benefit of providing a feature flag, namely, allowing opting in early to the new behavior, is not necessary here because users can "opt in" anyways by simply not using the deprecated commands. ### What is your fix for the problem, implemented in this PR? My fix is to remove the settings and check for `Bundler.feature_flag.bundler_3_mode?` instead. ### Why did you choose this fix out of the possible options? I chose this fix because it's simple and it makes it clear that keeping these commands and not something we want to support. They are going away for good. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Remove `console_command` settingremove_command_removal_settingsDavid Rodríguez2019-03-313-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This setting is not meant to be used by end users. The `console` command is going away and we plan to fully remove the code once we only have to maintain bundler 3 or higher versions. Adding a setting makes it look like the presence of this command is something "configurable", but it's not.
| * | | Remove `viz_command` settingDavid Rodríguez2019-03-313-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This setting is not meant to be used by end users. The `viz` command is going away and we plan to fully remove the code once we only have to maintain bundler 3 or higher versions. Adding a setting makes it look like the presence of this command is something "configurable", but it's not.
* | | | use pre.1 instead of beta.SHIBATA Hiroshi2019-04-021-1/+1
| | | |
* | | | Bump version to 2.1.0.beta1.SHIBATA Hiroshi2019-04-021-1/+1
| | | |
* | | | Merge #7007Bundlerbot2019-04-021-4/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7007: Remove lockfile incompatibility created by the `lockfile_uses_separate_rubygems_sources` setting r=deivid-rodriguez a=deivid-rodriguez This is more of a question PR, I created this patch to try it out and try to understand, not necessarily get it merged. ### What was the end-user problem that led to this PR? The problem was that once we enable the `lockfile_uses_separate_rubygems_sources` setting, all lockfiles in the world will become incompatible with the previous version. Actually, not necessarily incompatible, but bundler will reorder the sections when the setting is enabled, that will generate churn lock file diffs, and _maybe_ some confusion / merge conflicts, and so on. ### What was your diagnosis of the problem? My diagnosis was that maybe this is not necessary. I read over the issues where this setting was added and what I understood is that previously if a Gemfile specified multiple rubygems sources, they would all get merged together and that's dangerous because it's not deterministic from which source each gem will be picked up, and that could be maliciously exploited. So now each source gets its own separate section. However, how does that affect the ordering of the sections? I don't think it should affect it? ### What is your fix for the problem, implemented in this PR? My fix is to change the `lock_sources` method so that both code branches (`lockfile_uses_separate_rubygems_sources == true`, and `lockfile_uses_separate_rubygems_sources == false`) result in the same ordering of the source sections. ### Why did you choose this fix out of the possible options? I chose this fix because I _think_ it keeps the setting doing the same thing, but also keeps lock file compatibility. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove lockfile incompatibility due to a settingseparate_rubygems_sources_in_lockfileDavid Rodríguez2019-03-021-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `lockfile_uses_separate_rubygems_sources` was causing a lockfile incompatibility but in my opinion, this incompatibility is not necessary in the general case.
* | | | | Merge #6963Bundlerbot2019-04-011-0/+19
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6963: Allow to `bundle exec` default gems r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that since `irb` and others were moved to default gems, users cannot directly use them in a bundler context, unless they add it to their gemfiles. In my opinion, this completely defeats the purpose of default gems, and makes bundler degrade the user experience instead of making it better. ### What was your diagnosis of the problem? My diagnosis was that when bundler replaces the set of gems known to rubygems, it restricts the world to what's in the Gemfile (or resolved from it), and that doesn't include default gems. ### What is your fix for the problem, implemented in this PR? My fix is to also include the set of default gems, unless they are already included in the gemfile dependencies. ### Why did you choose this fix out of the possible options? I chose this fix because it's reasonably simple and I think it shouldn't affect how other parts of bundler function. Fixes #6929. Fixes https://bugs.ruby-lang.org/issues/15503. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
View Lorry Controller Status