summaryrefslogtreecommitdiff
path: root/spec
Commit message (Collapse)AuthorAgeFilesLines
* Merge #7248Bundlerbot2019-07-191-2/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+4
| |
* | Merge #7239Bundlerbot2019-07-154-28/+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-094-28/+2
| |
* | Merge #7247Bundlerbot2019-07-122-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-1/+1
| | |
| * | 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.
* | | 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-111-1/+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).
* | Remove now meaningless warningDavid Rodríguez2019-07-101-19/+0
| |
* | Add all platforms to lockfile by defaultDavid Rodríguez2019-07-102-5/+23
| |
* | Refactor some specsDavid Rodríguez2019-07-102-9/+9
|/
* Remove development dependencies from gemspecremove_add_development_dependency_from_gemspecDavid Rodríguez2019-07-081-2/+35
| | | | And refactor development setup.
* Remove unnecessary begin-end blockDavid Rodríguez2019-07-081-15/+13
| | | | And freeze the resulting hash to appease rubocop.
* Merge #7222Bundlerbot2019-07-061-9/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Generate new gem development dependencies in GemfileDavid Rodríguez2019-06-261-7/+17
| |
| * Fix local variable nameDavid Rodríguez2019-06-261-2/+2
| |
| * Reuse `execute_bundle_gem` methodDavid Rodríguez2019-06-261-2/+1
| |
* | Merge #7235Bundlerbot2019-07-067-22/+16
|\ \ | | | | | | | | | | | | | | | | | | | | | 7235: Spec improvements r=deivid-rodriguez a=deivid-rodriguez This is a bunch of miscelaneous commits that fix and improve some stuff in our test suite. I could open separate PRs for them but they are so small that I figured I could compile them all on a single PR. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix typosspec_improvementsDavid Rodríguez2019-07-051-4/+4
| | |
| * | Reuse `lockfile` spec helperDavid Rodríguez2019-07-052-7/+3
| | |
| * | Remove unused filterDavid Rodríguez2019-07-051-1/+0
| | |
| * | Reuse `gemfile` spec helperDavid Rodríguez2019-07-051-6/+4
| | |
| * | More specific assertionDavid Rodríguez2019-07-051-2/+2
| | | | | | | | | | | | 1.0.0 is such a common output, and it was hiding a crash in the test.
| * | Remove redundant assertionDavid Rodríguez2019-07-051-1/+0
| | |
| * | Make spec easier to debugDavid Rodríguez2019-07-051-1/+3
| | |
* | | Merge #7225Bundlerbot2019-07-051-3/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7225: Clearer `MissingRevision` git errors r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that sometimes we get the error "Revision xxxxxx does not exist in the repository https://github.com/my_user/my_repo. Maybe you misspelled?" ### What was your diagnosis of the problem? My diagnosis was that it's not always easy to troubleshoot this error, because you don't even know which git command failed in the first place. ### What is your fix for the problem, implemented in this PR? My fix is to also include in the error the command that originally failed. ### Why did you choose this fix out of the possible options? I chose this fix because I think it will help users with troubleshooting. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Improve spec to be more realisticclearer_git_errorsDavid Rodríguez2019-06-281-2/+3
| | | |
| * | | Clearer MissingRevision git errorsDavid Rodríguez2019-06-271-2/+5
| | | |
* | | | Merge #6113Bundlerbot2019-07-051-0/+29
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6113: [Package] Always resolve remotely for --all-platforms r=indirect a=segiddins ### What was the end-user problem that led to this PR? The problem was `bundle package --all-platforms` causes `bundle install` to ignore `--with` and `--without`. Closes https://github.com/bundler/bundler/issues/6074. ### What was your diagnosis of the problem? My diagnosis was `Installer#resolve_if_needed` had to always resolve remotely for `--all-platforms`, because we would be trying to package things that weren't available locally. ### Why did you choose this fix out of the possible options? I chose this fix because it avoids refactoring any of the other packaging code. Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | [Package] Ensure uninstallable gems are _never_ installedSamuel Giddins2019-07-051-2/+12
| | | |
| * | | [Package] Always resolve remotely for --all-platformsSamuel Giddins2019-07-051-0/+19
| | | |
* | | | Merge #7233Bundlerbot2019-07-051-0/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7233: Add missing expectation r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was I noticed that this test was missing one assertion. See https://github.com/bundler/bundler/blob/566cce0629a0f1a4d147195a34d494306269e1cf/lib/bundler/shared_helpers.rb#L77-L84 ### What was your diagnosis of the problem? My diagnosis was that it should be added. ### What is your fix for the problem, implemented in this PR? My fix is to add the missing expectation. ### Why did you choose this fix out of the possible options? I chose this fix because regardless of how implementation dependent this spec is, it should probably be complete. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Add missing mockmissing_mockDavid Rodríguez2019-07-041-0/+1
| |/ / | | | | | | | | | | | | I'm not sure this test is useful but since it's there, it should be complete.
* | | Merge #7212Bundlerbot2019-07-051-0/+28
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7212: Don't re-resolve locked platform specific gems r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that when you have locked platform gems in your lockfile for a platform different than the running one, the lockfile was always getting re-resolved. ### What was your diagnosis of the problem? My diagnosis was that the dependencies passed on to the `SpecSet#for` call that's supposed to check that no dependencies are missing for the current platform, always include all dependencies for all platforms. And thus platform missing dependencies are always detected. The reason for that is that `expand_dependencies` was being passed `remote = true` https://github.com/bundler/bundler/blob/0b5da910e71760eb585b34d08d43ea31b988ca24/lib/bundler/definition.rb#L815-L816 and thus not excluding dependencies exclusive for other platforms https://github.com/bundler/bundler/blob/0b5da910e71760eb585b34d08d43ea31b988ca24/lib/bundler/definition.rb#L887 ### What is your fix for the problem, implemented in this PR? My fix is to skip the second argument to `expand_dependencies` in this case, so that it works in its default "local mode" and the dependencies for other platforms are properly filtered out. ### Why did you choose this fix out of the possible options? I chose this fix because it fixes the issue in a simple way. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Don't re-resolve locked platform specific gemsDavid Rodríguez2019-06-251-0/+28
| | |/ | |/|
* | | Merge #7154Bundlerbot2019-07-041-0/+13
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7154: bundler/inline should install gems to BUNDLE_PATH r=deivid-rodriguez a=robuye ### What was the end-user problem that led to this PR? This addresses the problem described in issue #7131. `bundler/inline` does not respect `BUNDLE_PATH` env variable and installs gems to the default location. ### What was your diagnosis of the problem? `Bundler.configure` is not called at any point in `bundler/inline`. ### What is your fix for the problem, implemented in this PR? To call it :) ### Why did you choose this fix out of the possible options? When bundler is invoked via `bundle install` this method gets called. --- The included test is failing without this change as expected. I have also tested it manually using the code from the issue on ruby 2.6 and with bundler `1.17.2` & `2.0.1`. Co-authored-by: robuye <rulejczyk@gmail.com>
| * | bundler/inline should always install gems to system pathrobuye2019-06-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | As discussed in the P/R, when `BUNDLE_PATH` env is set Bundler should still install gems to the system path. `GEM_HOME` can be used to provide different location if needed. The test is added to document expected behavior of `bundler/inline`.
* | | RUBY_ENGINE should always be defined after 1.8.7ruby_engine_always_definedDavid Rodríguez2019-06-263-18/+8
| |/ |/|
* | Merge #7209Bundlerbot2019-06-241-12/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7209: Add a minimum ruby version to the generated gemspec r=hsbt a=deivid-rodriguez This PR is a finished version of #4397. ### What was the end-user problem that led to this PR? The problem was that the generated gemspec for new gems does not impose a minimum ruby version. ### What is your fix for the problem, implemented in this PR? My fix is to set the minimum ruby version in the generated gemspec to the minimum ruby version supported by bundler itself. ### Why did you choose this fix out of the possible options? I chose this fix because it's simple. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> Co-authored-by: Miklos Fazekas <mfazekas@szemafor.com>
| * | Add `required_ruby_version` to gemspec templategemspec-rrMiklos Fazekas2019-06-171-0/+6
| | |
| * | Factor out gemspec call inside `let`David Rodríguez2019-06-171-8/+8
| | |
| * | Remove duplicated `let`'sDavid Rodríguez2019-06-171-5/+2
| | |
* | | Merge #7161Bundlerbot2019-06-2494-1021/+1021
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7161: Fix file URIs on Windows r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that file:// URIs were not properly handled on Windows, and those are heavily used by our specs. ### What was your diagnosis of the problem? My diagnosis was that Windows paths do not start with a slash, so we need to add an extra slash to separate the host from the path in file:// urls. Otherwise "D:" is parsed as the host segment in the URI. As a consequence of that change, we also need to strip that leading character when using the path segment for those URIs, so that it's a valid file path on Windows. This change reduces Windows CI spec failures from 429 to 355. In order to apply this fix for all file URI's in tests, I extracted a helper method and searched and replaced all file:// ocurrences with the method. The diff is big because of that, but I think it works fine. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Fix file:// handling under WindowsDavid Rodríguez2019-06-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows paths do not start with a slash, so we add an extra slash to separate the host from the path in file:// urls. Otherwise "D:" is parsed as the host segment in the URI. The path for those URLs now starts with "/", so we ignore that leading character when using the URI's path. This reduces Windows CI spec failures from 429 to 355.
| * | | Normalize file:// handling in specsDavid Rodríguez2019-06-1194-1021/+1020
| | | |
* | | | Fix a typo on a spec commentfix_typoDavid Rodríguez2019-06-201-1/+1
| | | |
* | | | Use real paths for `bundle clean`use_real_git_pathsDavid Rodríguez2019-06-171-0/+26
| | | |
* | | | Fix thread leak in compact index specsDavid Rodríguez2019-06-171-1/+1
| |/ / |/| | | | | | | | | | | | | | This spec was not stopping threads after itself. That would cause the previous spec in the file (that checks that no threads are left behind) to fail.
View Lorry Controller Status