summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fix warning message about bundler versionfix_upgrade_instructionsDavid Rodríguez2019-02-183-5/+9
| | | | | | | 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.
* Merge #6968Bundlerbot2019-02-161-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6968: Travis "bundle gem" template: Drop unused sudo: false option r=deivid-rodriguez a=olleolleolle ### What was the end-user problem that led to this PR? I reviewed a PR in an Open Source project, and it had this defunct setting from Travis. ### What was your diagnosis of the problem? I was told the `bundle gem` command outputs this directive, and I looked here, and lo, it was. See https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration for historical detail about when it was removed. ### What is your fix for the problem, implemented in this PR? My fix is to **drop** this **unused directive** from the template. ### Why did you choose this fix out of the possible options? I chose this fix because it works the same for the user, with less configuration. Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
| * 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
* Merge #6899Bundlerbot2019-02-154-1/+87
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6899: Windows CI: Azure Pipelines r=colby-swandale a=janpio ### What was the end-user problem that led to this PR? When I wanted to start to work on #6841 by adding a few tests, I quickly learned that bundler's test suite does not pass on Windows: #6868 ### What was your diagnosis of the problem? I decided to start working on fixing this, and created a few issues already: https://github.com/bundler/bundler/search?q=%22%5BWindows+test+failure%5D%22&unscoped_q=%22%5BWindows+test+failure%5D%22&type=Issues But it become clear to me, that the only way to really track the improvement was to add CI for Windows - otherwise opening PRs with improvements would not really make sense. ### What is your fix for the problem, implemented in this PR? This PR first makes it possible to run the test suite on Windows at all by "hiding" a bit of code behind `Gem.win_platform?` (`Spec::Manpages.setup` made it super complicated to run on Windows - and is not really necessary to run the test suite). It also works around a strange bug concerning `thor`'s (a vendored dependency) use of `readline` which crashes in strange ways on Windows (see #6902). And it adds applies a patch to the `readline` implementation used on CI (via RubyInstaller ruby) that otherwise blocks the tests (see #6907). Then it adds CI configuration for Azure Pipelines, a free for OSS CI platform. I configured the Azure Pipelines build to create a JUnit compatible report if the test suite and display it in the "Tests" tab of the build. ### Why did you choose this fix out of the possible options? I think disabling this code for Windows is a valid choice to get the ball rolling, later this will undone and the underlying problem will be fixed. I chose the workarounds for #6902 and #6907 as I couldn't find a proper bugfix yet - so this will be one of the things to be fixed using Windows CI. Azure Pipelines is a great CI platform for Windows (and later even multiple platforms if we choose to also run the tests on Linux and macOS). I chose not to adapt the `rake travis` task (yet) because it is _much_ more complex than the "simple" `bin/rspec` test suite run which I could directly execute in the CI scripts of Azure Pipelines. Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com> Co-authored-by: Jan Piotrowski <piotrowski+github@gmail.com>
| * manually install rspec_junit_formatterJan Piotrowski2019-02-111-1/+5
| |
| * always exit `ruby bin/rspec` with code 0Jan Piotrowski2019-02-111-1/+1
| |
| * remove added dependencyJan Piotrowski2019-02-101-1/+0
| |
| * Merge branch 'master' into cross_platform_ciJan Piotrowski2019-01-2841-318/+72
| |\
| * | patch readline in site_ruby (workaround for #6907)Jan Piotrowski2019-01-142-1/+46
| | |
| * | avoid readline crash (workaround for #6902)Jan Piotrowski2019-01-141-0/+6
| | |
| * | Rudimentary Azure Pipelines CI configuration for WindowsJan Piotrowski2019-01-143-0/+32
| | |
| * | do not generate manpages on WindowsJan Piotrowski2019-01-111-1/+1
| | |
* | | Merge #6949Bundlerbot2019-02-1466-391/+368
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6949: Split test assertions by stream r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that once we enable deprecations, they will start getting printed to the screen and will affect existing output assertions, thus breaking unrelated tests. ### What was your diagnosis of the problem? My diagnosis was that we started printing errors to the stderr stream in bundler 2, but our `out` test helper [checks both streams combined](). That means deprecations affect the result of this helper, and any test runninng commands that print deprecations and checking for the exact output will be affected. ### What is your fix for the problem, implemented in this PR? My fix is to consider only output in the `out` helper, and error in the `err` helper. That involves a simple change in the helper to return only `stdout` instead of `stdboth`, and fixing a bunch of tests that used to check `out` for errors and now need to check `err`. ### Why did you choose this fix out of the possible options? I chose this fix because even if it was tedious, it simplifies enabling deprecations, and slightly improves the readability of tests. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Fix 1.x specscheck_out_only_in_specsDavid Rodríguez2019-02-1420-72/+72
| | | |
| * | | Remove now unnecessary `lack_errors` matcherDavid Rodríguez2019-02-1412-38/+31
| | | | | | | | | | | | | | | | | | | | Since the errors are checked on their own stream, no filtering is needed.
| * | | Split stderr and stdout in specsDavid Rodríguez2019-02-1455-304/+287
| | | |
| * | | 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-142-5/+6
| | | |
| * | | Fix typoDavid Rodríguez2019-02-141-1/+1
| | | |
* | | | Merge #6945Bundlerbot2019-02-141-0/+11
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6945: Add stale issues section to bug triage doc r=colby-swandale a=esasse As discussed on Slack, this is the suggested process to deal with stale issues. /cc @colby-swandale Co-authored-by: Erick Sasse <esasse@gmail.com>
| * | | Add stale issues sectionErick Sasse2019-02-051-0/+11
| | | |
* | | | Merge #6964Bundlerbot2019-02-131-13/+6
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6964: Dependency review r=segiddins a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we were using some outdated test dependencies. ### What was your diagnosis of the problem? My diagnosis was that we can upgrade them, since the comments justifying them being pinned are no longer relevant. ### What is your fix for the problem, implemented in this PR? My fix is to unpin the dependencies, and remove the comments no longer applying. ### Why did you choose this fix out of the possible options? I chose this fix because it was the only fix I could think of. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove exception since MRI 1.9.3 is no longer supporteddependency_reviewDavid Rodríguez2019-02-131-4/+3
| | | | |
| * | | | Bump builder gem since we no longer support MRI 1.9.2David Rodríguez2019-02-131-2/+1
| | | | |
| * | | | Bump rack-test since we no longer support MRI 1.8.7David Rodríguez2019-02-131-3/+1
| | | | |
| * | | | Fix TODO note since linked issue seems closedDavid Rodríguez2019-02-131-3/+1
| | | | |
| * | | | Remove no longer relevant commentDavid Rodríguez2019-02-131-1/+0
| | | | | | | | | | | | | | | | | | | | Ruby 2.2.2 is no longer supported.
* | | | | Merge #6962Bundlerbot2019-02-135-29/+22
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6962: Don't leak to system rubygems during specs r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that sometimes one get warnings on the system rubygems files, or maybe when modifying the `tmp` copy of rubygems, the changes seem not applied. ### What was your diagnosis of the problem? My diagnosis was our specs sometimes use the system rubygems version, not the one controlled by the `RVG` environment variable. ### What is your fix for the problem, implemented in this PR? My fix is to remove most occurrences of `:env => { :RUBYOPT => "-r#{spec_dir.join("support/hax")}" }` when spawning subprocesses. The reason is that in order to use the tmp copy of rubygems, our specs need to include `-I tmp/rubygems/lib` in the `RUBYOPT` environment variable. If we overwrite it in subprocesses, it won't use it. We can remove those however, since the "hax file" is already included in the main spec helper, while also keeping the previous value of `RUBYOPT`. https://github.com/bundler/bundler/blob/189d56f2341d64ec5440242f42dbf84002be1238/spec/spec_helper.rb#L47 ### Why did you choose this fix out of the possible options? I chose this fix because it simplifies the spec setup while also making it more correct. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove now unnecessary stuff from helper methodrubygems_leakageDavid Rodríguez2019-02-121-5/+2
| | | | |
| * | | | Spec behaves consistenly across OS's apparentlyDavid Rodríguez2019-02-121-1/+1
| | | | |
| * | | | Stop leaking to system rubygems on subprocessesDavid Rodríguez2019-02-125-24/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to be able to test against different versions of rubygems, we prepend our local copy of rubygems to the $LOAD_PATH. This is done as early as possible, inside each binstubs through [this helper file]. However, some subprocesses overwrite the `RUBYOPT` env variable, thus leaking to the system copy of rubygems again. Since we already [prepend the hacks file] to `RUBYOPT` in the main helper, while also preserving the previous value, this "customized environments" are not needed.
* | | | | Merge #6958Bundlerbot2019-02-132-6/+2
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6958: Remove rdiscount indirect development dependency r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I was confused about the `rdiscount` dependency since I didn't see it used anywhere. ### What was your diagnosis of the problem? My diagnosis was that it's just an indirect dependency (through ronn). ### What is your fix for the problem, implemented in this PR? My fix is to remove the dependency. ### Why did you choose this fix out of the possible options? I chose this fix because it will no longer confuse devs into thinking we're actually using it directly. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove rdiscount indirect dependencyremove_rdiscount_indirect_dependencyDavid Rodríguez2019-02-112-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't use this dependency directly so this is not needed. We put it there at some point because we needed to pin to a specific version, but that's no longer the case.
* | | | | Merge #6959Bundlerbot2019-02-121-1/+1
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6959: Bump base rubygems version to 3.0.2 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we are using old rubygems versions internally. ### What was your diagnosis of the problem? My diagnosis was that we should use the newest version of our own software. ### What is your fix for the problem, implemented in this PR? My fix is to upgrade the rubygems version used in the Rakefile for development tasks. ### Why did you choose this fix out of the possible options? I chose this fix because it's good for us. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Bump base rubygems version to 3.0.2bump_base_rubygems_versionDavid Rodríguez2019-02-121-1/+1
|/ / / /
* | | | Merge #6950Bundlerbot2019-02-111-8/+10
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6950: Clean up first `bin/rake spec:deps` output r=deivid-rodriguez a=deivid-rodriguez Thanks so much for the contribution! To make reviewing this PR a bit easier, please fill out answers to the following questions. ### What was the end-user problem that led to this PR? The problem was that on a fresh ruby install (docker, I'm looking at you), running `bin/rake spec:deps` prints the following errors, even if nothing end up going wrong and the dependencies get installed: ``` Could not find 'automatiek' (~> 0.1.0) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'mustache' (= 0.99.6) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rake' (~> 12.0) - did find: [rake-10.4.2] Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecVersionError) Could not find 'rdiscount' (~> 2.2) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'ronn' (~> 0.7.3) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rspec' (~> 3.6) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rubocop' (= 0.50.0) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) ``` ### What was your diagnosis of the problem? My diagnosis was that the rake's binstub tries to activate the development depedencies even in the case when we're installing them. In that case, they will most likely not be installed, and give errors. ### What is your fix for the problem, implemented in this PR? My fix is to exclude development dependency activation in this specific case. ### Why did you choose this fix out of the possible options? I chose this fix because it's simple and fixes the problem. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Clean up first `bin/rake spec:deps` outputclean_rake_spec_depsDavid Rodríguez2019-02-091-8/+10
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the first time you run `bin/rake spec:deps` on a fresh installation, you get the following output: ``` Could not find 'automatiek' (~> 0.1.0) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'mustache' (= 0.99.6) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rake' (~> 12.0) - did find: [rake-10.4.2] Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecVersionError) Could not find 'rdiscount' (~> 2.2) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'ronn' (~> 0.7.3) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rspec' (~> 3.6) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) Could not find 'rubocop' (= 0.50.0) among 17 total gem(s) Checked in 'GEM_PATH=/usr/local/rvm/gems/ruby-2.3.7:/usr/local/rvm/gems/ruby-2.3.7@global', execute `gem env` for more information (Gem::MissingSpecError) ``` Nothing has gone wrong but the user might think the opposite. So, avoid printing these errors.
* | | | Merge #6954Bundlerbot2019-02-104-10/+10
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6954: Bump test MRI 2.3 version in TravisCI r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we don't know whether bundler works against the latest patch level version of MRI 2.3. ### What was your diagnosis of the problem? My diagnosis was that we should test it. ### What is your fix for the problem, implemented in this PR? My fix is to bump the 2.3 matrix entries in TravisCI config to 2.3.8. This MRI version comes with rubygems 2.7.8, so bump that too. ### Why did you choose this fix out of the possible options? I chose this fix because it's the only one, given the CI setup we currently have. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Bump Travis entries to use rubygems 2.7.8bump_base_rubygems_and_ruby_2.3_in_travisDavid Rodríguez2019-02-102-5/+5
| | | | |
| * | | | Bump Travis entries to use MRI 2.3.8David Rodríguez2019-02-101-3/+3
| | | | |
| * | | | Properly restrict rubygems version for failing specsDavid Rodríguez2019-02-102-2/+2
|/ / / / | | | | | | | | | | | | | | | | These specs need https://github.com/rubygems/rubygems/pull/1527 to pass, so restrict them to rubygems version containing that.
* | | | Merge #6948Bundlerbot2019-02-102-5/+12
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6948: Bump rubygems to 3.0.2 and ruby to 2.6.1 in TravisCI r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I have some spec failures locally, and they don't seem to be reproduced in TravisCI. ### What was your diagnosis of the problem? My diagnosis was that either my environment is messed up or there's some issues with the latest rubygems + ruby combination. ### What is your fix for the problem, implemented in this PR? My fix is to use latest rubygems and ruby in Travis, so I can double check whether the problem is just my environment or a real problem. ### Why did you choose this fix out of the possible options? I chose this fix because it's always good practice to test against the latest versions of your dependencies. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Bump main tested rubygems to 3.0.2travis_experimentsDavid Rodríguez2019-02-082-2/+2
| | | | |
| * | | | Bump main tested ruby to 2.6.1David Rodríguez2019-02-082-3/+10
| |/ / /
* | | | Merge #6952Bundlerbot2019-02-091-0/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6952: Bump TravisCI build to Xenial r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that CI in #6938 is failing, and I'm not sure why. ### What was your diagnosis of the problem? My diagnosis was that I should split the two changes made in that PR to find out the culprit. ### What is your fix for the problem, implemented in this PR? My fix is to split the TravisCI update to xenial, because my guess is that this is not the culprit, so if the build is green, we can merge this and upgrade :tada: ### Why did you choose this fix out of the possible options? I chose this fix because it means no work for me, just delegate to TravisCI. :) Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Bump TravisCI build to XenialxenialDavid Rodríguez2019-02-091-0/+1
|/ / /
* | | Merge #6941Bundlerbot2019-02-052-1/+11
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6941: Ignore to add bundler lib direcotry if it is same as rubylibdir r=hsbt a=hsbt ### What was the end-user problem that led to this PR? 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 a specific version. Fixed https://bugs.ruby-lang.org/issues/15469 ### What was your diagnosis of the problem? See the details: https://bugs.ruby-lang.org/issues/15469#note-4 ### What is your fix for the problem, implemented in this PR? I avoid adding bundler directory from RUBYLIB environmental variable Because its directory was already added $LOAD_PATH. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | | 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-042-1/+10
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
View Lorry Controller Status