summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Delay `bundle console` removal to bundler 3David Rodríguez2019-02-281-1/+1
|
* Delay requiring --all to update everything to bundler 3David Rodríguez2019-02-281-1/+1
| | | | Since we haven't even yet deprecated the old behavior.
* Remove rubygems compatibility guardremove_unnecessary_rubygems_filtersDavid Rodríguez2019-02-251-4/+0
| | | | Bundler 2 can't be installed on these rubygems, so it's not necessary.
* Remove more unnecessary rubygems version checksDavid Rodríguez2019-02-252-33/+18
|
* Remove unnecessary old rubygems deprecationDavid Rodríguez2019-02-251-7/+3
|
* Merge #6971Bundlerbot2019-02-241-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6971: Fix warning message about bundler version r=colby-swandale a=deivid-rodriguez Fixes #6909. ### What was the end-user problem that led to this PR? The problem was that we're recommending a command to make a warning go away that doesn't really make the warning go away. ### What was your diagnosis of the problem? My diagnosis was that the current recommendation installs the latest bundler, which might not be the same as the version the lock file was created with. If it's not the same, the warning will not go away. ### What is your fix for the problem, implemented in this PR? My fix is to recommend installing exactly the version the lockfile was created with. ### Why did you choose this fix out of the possible options? I chose this fix because it's really simple and it should work. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix warning message about bundler versionfix_upgrade_instructionsDavid Rodríguez2019-02-181-3/+3
| | | | | | | | | | | | | | To actually make the warning go away, we need to recommend exactly installing the locked version. Otherwise the latest version gets installed, but not used to being a different major than the one locked, so the warning stays.
* | Remove ruby version major deprecationDavid Rodríguez2019-02-221-3/+0
| | | | | | | | Since the current master will never run those rubies.
* | Rename major_deprecations to silence_deprecationsdeprecation_changesDavid Rodríguez2019-02-212-3/+3
| |
* | Fix deprecations bugDavid Rodríguez2019-02-211-1/+1
| | | | | | | | | | Deprecations enabled or not, we only want to print deprecations for the running major version, never for future versions.
* | Remove major_deprecations feature flagDavid Rodríguez2019-02-213-2/+2
| | | | | | | | Leave it as a setting with default true value.
* | Turn on deprecations by defaultDavid Rodríguez2019-02-212-1/+2
| |
* | Remove deprecation releasesDavid Rodríguez2019-02-211-2/+1
| |
* | Reword deprecation messagesDavid Rodríguez2019-02-211-2/+2
| | | | | | | | | | | | Including the version is confusing, in my opinion, because it's unclear whether it refers to the future version of removal, or to the current running version.
* | Merge #6974Bundlerbot2019-02-2011-21/+26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6974: Use newer list interface r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our specs emit a lot of deprecations about the list command. ### What was your diagnosis of the problem? My diagnosis was that we are using the deprecated interface to the list command everywhere. ### What is your fix for the problem, implemented in this PR? My fix is to start using the new interface. If we don't use it ourselves, how could we be in a position to tell our users to start using it? ### Why did you choose this fix out of the possible options? I chose this fix because we should do this, at same point, and doing it now simplifies enabling deprecations. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Slightly better wording of error messagesuse_newer_list_interfaceDavid Rodríguez2019-02-201-2/+2
| | |
| * | Fix git source error message recommendationsDavid Rodríguez2019-02-201-2/+7
| | | | | | | | | | | | So the we suggest an actually working command.
| * | Use newest interface to `bundle config` everywhereDavid Rodríguez2019-02-1911-20/+20
| |/
* | Use ENV["BUNDLE_GEM"] instead of gem command provided by system ruby.SHIBATA Hiroshi2019-02-191-2/+4
| | | | | | | | | | It break the examples of bundler. Because some examples detect the different version of system ruby than test target version like trunk.
* | Fixup r66984. It breakes bundler's examples.SHIBATA Hiroshi2019-02-191-1/+1
|/
* Travis template: Drop unused sudo: false optionOlle Jonsson2019-02-161-1/+0
| | | - See https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration for historical detail
* Fix show command output/error streamsDavid Rodríguez2019-02-141-1/+1
| | | | Before it was printing half a sentence to stderr and half to stdout.
* Print git errors to a consistent streamDavid Rodríguez2019-02-141-1/+1
|
* Print to correct stream when setup on a ttyDavid Rodríguez2019-02-141-3/+4
|
* Added explicitly loading for RbConfig.SHIBATA Hiroshi2019-02-051-0/+1
|
* Ignore to add bundler lib direcotry if it is same as ↵ignore-bundler-lib-ruby-libSHIBATA Hiroshi2019-02-041-1/+1
| | | | | | | | | | | | | RbConfig::CONFIG["rubylibdir"]. https://bugs.ruby-lang.org/issues/15469 In ruby core, the bundled bundler was located same as rubylibdir. When user used the specific version of default gems like json, Bundler uses default gems under the rubylibdir, not specific version. I avoid to add bundler directory from RUBYLIB enviromental variable, Because its directory was already added $LOAD_PATH.
* Merge #6931Bundlerbot2019-01-292-0/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6931: Add patch option in bundle config r=greysteil a=ankitkataria ### What was the end-user problem that led to this PR? Issue #5994 ### What was your diagnosis of the problem? As mentioned by @indirect I added a `patch` option in the bundler config, which by default is false. If set to true, patch level update are preferred if no update levels are specified. ### What is your fix for the problem, implemented in this PR? A patch level config option which can be opted into. Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
| * resolve compatibility issuesAnkit Kataria2019-01-271-1/+1
| |
| * change prefer to patch_prefer and updated help textAnkit Kataria2019-01-272-3/+3
| |
| * update bundle config man pageAnkit Kataria2019-01-241-2/+2
| |
| * add patch option in bundle configAnkit Kataria2019-01-242-0/+4
| |
* | Replace unsafe http URLs with https URLsTakumasa Ochi2019-01-281-2/+2
| |
* | Bump rake version to 12.0 on gemspec template. Because rake-10.0 is EOL now.SHIBATA Hiroshi2019-01-241-1/+1
| |
* | Merge #6315Bundlerbot2019-01-232-30/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6315: Removed compatibility hack for old rubies. r=hsbt a=hsbt ### What was the end-user problem that led to this PR? Nothing. ### What is your fix for the problem, implemented in this PR? Bundler will never use them in version 2. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * \ Merge branch 'master' into remove-old-rubySHIBATA Hiroshi2019-01-1222-84/+160
| |\ \
| * | | Removed compatibility hack for old rubies.SHIBATA Hiroshi2018-10-173-34/+9
| | | |
* | | | Merge #6884Bundlerbot2019-01-231-1/+1
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6884: Remove unnecessary condition r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that some code in the feature flags implementation seemed uncovered. ### What was your diagnosis of the problem? My diagnosis was that the code should be either covered or removed. ### What is your fix for the problem, implemented in this PR? My fix was to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because the scenario where that code would get covered is more likely to be unintentional and risk introducing a bug. Defining a feature flag without a default block is the same as don't defining a feature flag and just relying on the default value for the setting. In these circumstances, it's more likely that the developer forgot to include a default block, so letting that case crash would be better, I think. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Remove unnecessary conditionremove_unnecessary_conditionDavid Rodríguez2019-01-071-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | This is currently dead code because all feature flags specify a default block. With the current implementation, if we ever defined a feature flag without specifying a default block, it would instead return the default setting value. I think it is better to raise an error in that case, since it would probably be an overlook and not something intentional.
* | | Ensure credentials are masked in FallbackError from Net::HTTPNotFoundgreysteil/show-notfound-uriGrey Baker2019-01-141-1/+1
| | |
* | | Include URL in Bundler::Fetcher::FallbackError message for Net::HTTPNotFoundGrey Baker2019-01-031-1/+1
|/ /
* | Merge #6856Bundlerbot2018-12-302-5/+21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6856: Test against Ruby 2.6 and RubyGems 3 r=colby-swandale a=segiddins ### What was the end-user problem that led to this PR? The problem was we weren't testing our compatibility with the latest and greatest. Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: Colby Swandale <me@colby.fyi>
| * | Fix specs that are broken in ruby 2.6Samuel Giddins2018-12-281-5/+20
| | |
| * | Test against Ruby 2.6 and RubyGems 3Samuel Giddins2018-12-281-0/+1
| | |
* | | Merge #6843Bundlerbot2018-12-281-4/+26
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6843: Improve `clean_env` deprecation path r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I noticed that there's still some use cases where the current implementation of `Bundler.with_clean_env` can be useful. Whereas the most common use case is to go back to the original environment before bundler was loaded, sometimes you actually want a fully "unbundled" environment. For example, I wanted to test a rails template in isolation (`rails new my_app -m my_template.rb`) in a library where we specifically set `BUNDLE_GEMFILE` in CI. In that context, `with_original_env` won't do the trick for me, because to properly test my template i need to make sure no bundler environment is set at all. ### What was your diagnosis of the problem? My diagnosis was that we should probably undeprecate `(with_)clean_env`. But @indirect suggested that we should still deprecate the method name, because it's confusing what each developer understands by "clean". That's a very good point. ### What is your fix for the problem, implemented in this PR? My fix is to move the functionality of `(with_)clean_env` to `(with_)unbundled_env`, and deprecate `(with_)clean_env`. In addition, I noticed that the current deprecation message for `with_clean_env` actually mentioned the method `clean_env`, which is not a method the end user is using directly. So I changed the deprecation messages to suggest the proper alternative for each case (suggest `unbundled_env` as a replacement for `clean_env`; and `with_unbundled_env` as a replacement for `with_clean_env`). ### Why did you choose this fix out of the possible options? I chose this fix because it undeprecates the functionality previously provided by `clean_env`, while still deprecating the `clean_env` name because of being confusing. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Properly deprecate `with_clean_env`David Rodríguez2018-12-191-2/+8
| | | | | | | | | | | | | | | Previously the deprecation would point to the `Bundler.clean_env` method even if not directly used by the end user.
| * | Introduce `with_unbundled_env`David Rodríguez2018-12-191-0/+5
| | | | | | | | | | | | As a replacement to `with_clean_env`.
| * | Add docs for existing helpersDavid Rodríguez2018-12-191-0/+2
| | |
| * | Deprecate `clean_env` in favor of `unbundled_env`David Rodríguez2018-12-191-3/+12
| | | | | | | | | | | | And thus, deprecate only the name, but not the functionality.
| * | Improve `clean_env` deprecation messageDavid Rodríguez2018-12-191-1/+1
| | |
View Lorry Controller Status