summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Load Digest::SHA2 using Digest()colby/flaky-testColby Swandale2017-10-142-2/+2
|
* Auto merge of #6036 - nobu:feature/sh-by-popen, r=indirectThe Bundler Bot2017-10-041-23/+49
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call IO.popen instead of backticks IO.popen with the command in an array doesn't need command line quotes, and is safer. 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? Back-ticks with command line quoting is dangerous. ### What was your diagnosis of the problem? Back-ticks is not for complex purpose. ### What is your fix for the problem, implemented in this PR? Use `IO.popen` and redirection option instead. ### Why did you choose this fix out of the possible options? `IO.popen` and options of `spawn` have been introduced for such purpose.
| * Support 1.8Nobuyoshi Nakada2017-09-191-7/+22
| |
| * Get rid of rubocop's grumblesNobuyoshi Nakada2017-09-191-11/+13
| |
| * Fix variableNobuyoshi Nakada2017-09-191-1/+1
| |
| * Call IO.popen instead of backticksNobuyoshi Nakada2017-09-171-20/+29
| | | | | | | | | | IO.popen with the command in an array doesn't need command line quotes, and is safer.
* | Auto merge of #6053 - arbonap:pa-git-error-dbundle, r=indirectThe Bundler Bot2017-10-041-1/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass gemspec directory path to Git ### What was the end-user problem that led to this PR? The problem was... - This WIP PR tries to solve Issue #6029 - When running commands like `dbundle -v` as described in [SETUP.md](https://github.com/bundler/bundler/blob/master/doc/development/SETUP.md#development-setup), commands give us a git error. ### What was your diagnosis of the problem? - Like stated in Issue #6029, the git option `-C` should be used to pass the directory containing the gemspec file to the git command. My diagnosis was... - to give git the correct directory path where the gemspec file is ### What is your fix for the problem, implemented in this PR? My fix... - I'm wondering if I'm on the right track with this? - So, I ran `bin/rspec /spec/install/gemfile/gemspec_spec` and the specs passed. I then run the entire test suite and the `gemspec_spec` and a few other specs fail throughout the test suite. Then, I re-ran the failing specs files individually-- both as a whole, as well as on the failing lines, and yet they're green. I'm assuming I'll similarly get failing specs on Travis. I'm not really familiar with how to troubleshoot test suites with test pollution. - Could folks point me in the right direction? Any help would be much appreciated! ### Why did you choose this fix out of the possible options? I chose this fix because... - I chose to `require "pathname"`because I found it more intuitive to manipulate file paths with that library.
| * | Pass gemspec directory path to GitPatricia Arbona2017-09-281-1/+3
| | |
* | | Auto merge of #5889 - bundler:rubymorillo-patch-4, r=colby-swandaleThe Bundler Bot2017-10-011-1/+6
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added a sentence to `binstubs` Per feedback from @arbonap, we've added a sentence that briefly explains what binstubs is to the binstubs section. 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...no understanding of what binstubs is. Added a quick two sentences! ### What was your diagnosis of the problem? My diagnosis was...we needed some language there. @arbonap and @indirect pointed this out and offered the explanations. ### What is your fix for the problem, implemented in this PR? My fix...was to turn their explanations into simple language! ### Why did you choose this fix out of the possible options? I chose this fix because...it'll help users understand binstubs better
| * | | removed more whitespacerubymorillo-patch-4Stephanie Morillo2017-09-201-1/+1
| | | | | | | | | | | | from line 54
| * | | Removed extra whitespace in line 54Stephanie Morillo2017-09-151-1/+1
| | | | | | | | | | | | (Fingers crossed!)
| * | | Removed whitespaceStephanie Morillo2017-07-211-1/+1
| | | | | | | | | | | | From line 51
| * | | Added a sentence to `binstubs`Stephanie Morillo2017-07-201-1/+6
| | | | | | | | | | | | Per feedback from @arbonap, we've added a sentence that briefly explains what binstubs is to the binstubs section.
* | | | Auto merge of #6059 - walf443:rubocop_parallel, r=colby-swandaleThe Bundler Bot2017-10-011-1/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use rubocop --parallel option ### What was the end-user problem that led to this PR? No ### What is your fix for the problem, implemented in this PR? My fix enable rubocop's parallel option. This may improve rubocop's test time.
| * | | | use rubocop --parallel optionKeiji Yoshimi2017-09-241-1/+2
| | | | |
* | | | | Auto merge of #6068 - koic:update_newgem_readme_template_for_bundler2, ↵The Bundler Bot2017-09-291-1/+1
|\ \ \ \ \ | |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r=colby-swandale Update newgem README.md template for Bundler 2 ### What was the end-user problem that led to this PR? `bundle` command has been changed to display list of commands with Bundle 2. ```console % bundle Bundler version 2.0.0.dev (2017-09-29 commit 5e9c40aa1) Bundler commands: Primary commands: bundle install [OPTIONS] # Install the current environment to the system bundle update [OPTIONS] # Update the current environment bundle cache [OPTIONS] # Locks and then caches all of the gems into vendor/cache bundle exec [OPTIONS] # Run the command in context of the bundle bundle config NAME [VALUE] # Retrieve or set a configuration value bundle help [COMMAND] # Describe available commands or one specific command (snip) ``` Therefore, it can not be installed with `bundle` command written in README.md created by `bundle gem`. ### What was your diagnosis of the problem? It is the same as above. ### What is your fix for the problem, implemented in this PR? I think that it is better to write `bundle install` in the README template of `bundle gem`.
| * | | | Update newgem README.md template for Bundler 2Koichi ITO2017-09-291-1/+1
|/ / / /
* | | | Auto merge of #6056 - walf443:update_gem2.16.13, r=colby-swandaleThe Bundler Bot2017-09-281-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | update rubygems to v2.6.13 ### What was the end-user problem that led to this PR? rubygems v2.6.12 has important security issues. So, It's better to update v2.6.13 to rubygems. http://blog.rubygems.org/2017/08/27/2.6.13-released.html
| * | | update rubygems to v2.6.13Keiji Yoshimi2017-09-241-1/+1
|/ / /
* | | Auto merge of #6057 - walf443:update_ruby, r=colby-swandaleThe Bundler Bot2017-09-241-4/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | update ruby version to v2.3.4 to v2.3.5, v2.4.1 to v2.4.2 https://www.ruby-lang.org/en/news/2017/09/14/ruby-2-3-5-released/ https://www.ruby-lang.org/en/news/2017/09/14/ruby-2-4-2-released/
| * | | update ruby version to v2.3.4 to v2.3.5, v2.4.1 to v2.4.2Keiji Yoshimi2017-09-231-4/+4
|/ / /
* | | Auto merge of #6038 - bundler:colby/rubocop-050, r=olleolleolleThe Bundler Bot2017-09-183-59/+97
|\ \ \ | | | | | | | | | | | | | | | | | | | | update rubocop to 0.50 This PR just updates rubocop to 0.50
| * | | update rubocop to 0.50colby/rubocop-050Colby Swandale2017-09-183-59/+97
| | |/ | |/|
* | | Auto merge of #6024 - gwerbin:custom-user-bundle-dir, r=colby-swandaleThe Bundler Bot2017-09-184-10/+82
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow user to override ~/.bundle with environment variables ### What was the end-user problem that led to this PR? As in #4333, users wanted a way to make Bundler respect the XDG specification. ### What was your diagnosis of the problem? The directory `~/.bundle` was hard-coded and could not be configured. ### What is your fix for the problem, implemented in this PR? Allow users to configure `~/.bundle` and its relevant sub-directories by setting environment variables. The environment variables and their fallbacks are as follows: | variable | fallback if unset | |---|---| | `BUNDLE_USER_HOME` | `$HOME/.bundle` | | `BUNDLE_USER_CACHE` | `$BUNDLE_USER_HOME/cache` | | `BUNDLE_USER_CONFIG` | `$BUNDLE_USER_HOME/config` | | `BUNDLE_USER_PLUGIN` | `$BUNDLE_USER_HOME/plugin` | ### Why did you choose this fix out of the possible options? Unlike https://github.com/bundler/bundler/pull/5787, This solution is not specific to the XDG specification. Users have all kinds of setups, and this is a very general system for allowing them to configure their development machines however they need. It tries to keep all files created by Bundler in the same place (as per https://github.com/bundler/bundler/pull/5787#issuecomment-310154273), but allows the user to override that convention _if they really want to and they know what they are doing_. If they want to use XDG for everything, they can do it by explicitly setting the `BUNDLE_USER_*` variables to the equivalent `XDG_DATA_*`. If they just want to get `.bundle` out of their home directory, they can do it by setting `BUNDLE_USER_HOME` and don't have to mess with the more specific env variables if they don't want to. To me, this solution strikes the right balance between "fine-grained control for power users" and "simple, sane defaults for everyone else". Please let me know if my tests can be improved. My only Ruby experience so far has been writing Homebrew formulas and configuring Jekyll, so I'm sure I have a lot to learn.
| * | Conform to code styleGreg Werbin2017-09-111-1/+1
| | |
| * | Conform to code styleGreg Werbin2017-09-112-13/+12
| | |
| * | Make tests greenGreg Werbin2017-09-111-38/+43
| | |
| * | Remove unnecessary methodGreg Werbin2017-09-111-12/+9
| | |
| * | Use tests from the old commitGreg Werbin2017-09-101-0/+54
| | | | | | | | | | | | | | | Mostly unmodified tests from PR 5787 (not linked here to respect contribution guidelines).
| * | Allow the user to set alternative to ~/.bundleGreg Werbin2017-09-103-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recognize new environment variables, with the following fallbacks: $BUNDLE_USER_HOME -> $HOME/.bundle $BUNDLE_USER_CACHE -> $BUNDLE_USER_HOME/cache $BUNDLE_USER_CONFIG -> $BUNDLE_USER_HOME/config $BUNDLE_USER_PLUGIN -> $BUNDLE_USER_HOME/plugin TODOs: - Error handling in Bundler.user_bundle_path when an invalid option is passed - Add tests (see https://github.com/bundler/bundler/pull/5787/commits/47fbe99387fea73fa652ad6692349b24cad6fe2e) - Draft PR with reference to GitHub issue numbers (not linked here as per contributing guidelines) + Issue: 4333 + Pull request: 5787
* | | Auto merge of #6010 - bundler:seg-remove-failed-gem-download, r=indirectThe Bundler Bot2017-09-152-2/+27
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Source::Rubygems] Remove .gem if downloaded package is invalid ### What was the end-user problem that led to this PR? The problem was the user could (once) have downloaded a `.gem` file that isn't actually a `.gem`, and that package would poison their cache. Closes https://github.com/bundler/bundler/issues/5941. ### What was your diagnosis of the problem? My diagnosis was we should remove the `.gem` right after downloading it if we can't open it. ### What is your fix for the problem, implemented in this PR? My fix `rm_rf`'s the `.gem` on failure. ### Why did you choose this fix out of the possible options? I chose this fix because it won't accidentally nuke existing cache entries for a user, but it should help prevent Bundler propagating an issue.
| * | | [Source::Rubygems] Remove .gem if downloaded package is invalidseg-remove-failed-gem-downloadSamuel Giddins2017-09-062-2/+27
| | | |
* | | | Auto merge of #6030 - bundler:seg-outdated-filter-options, r=indirectThe Bundler Bot2017-09-144-10/+12
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [CLI] Switch around the --strict option for bundle outdated ### What was the end-user problem that led to this PR? The problem was > outdated would be more consistent to change --strict to --filter-strict and --update-strict to --strict ### What was your diagnosis of the problem? My diagnosis was > let's rename --strict to --filter-strict and rename the current --update-strict to --strict. In another ticket, later, we can expand the way outdated works to not need as many flags to show the relevant info ### What is your fix for the problem, implemented in this PR? My fix switches around the options, by just making `--strict` an alias that means something different on 2.0 than on 1.0 ### Why did you choose this fix out of the possible options? I chose this fix because it allowed keeping temporary 1.x compatibility, versus wholesale renaming of the option.
| * | | | [CLI] Switch around the --strict option for bundle outdatedseg-outdated-filter-optionsSamuel Giddins2017-09-134-10/+12
| | | | |
* | | | | Auto merge of #6031 - bundler:seg-disable-new-version-warning-by-default, ↵The Bundler Bot2017-09-142-0/+3
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r=indirect [CLI] For now, disable the new version warning by default ### What was the end-user problem that led to this PR? The problem was people were getting confused by the terseness and bluntness of the current outdated bundler version warning. ### What was your diagnosis of the problem? My diagnosis was we need to spend time fine-tuning the message, including when it is displayed. But given the lack of time to do so immediately, I thought it best to disable the warning for now, until someone can make a PR that addresses the comments and concerns raised in #6004.
| * | | | | [CLI] For now, disable the new version warning by defaultseg-disable-new-version-warning-by-defaultSamuel Giddins2017-09-132-0/+3
| |/ / / /
* | | | | Auto merge of #6022 - bundler:seg-fix-fetcher-regression, r=colby-swandaleThe Bundler Bot2017-09-1311-53/+122
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid making unnecessary network requests fetching specs ### What was the end-user problem that led to this PR? The problem was installing `source "https://rubygems.org"; gem "rack"` could cause bundler to make requests for _hundreds_ of specs, drastically slowing down installation. This was a regression in 1.16 caused by the new source pinning logic. ### What was your diagnosis of the problem? My diagnosis was the "double checking" step of creating the definition's index was accidentally saying Bundler needed to download specs for _every gem installed_, along with their dependencies _for every version in existence_. ### What is your fix for the problem, implemented in this PR? My fix narrows down the set of names that need to be double-checked for to (a) only those that could possibly be needed for resolution (b) and only those specs that could possibly come from many sources (i.e. are "unpinned") ### Why did you choose this fix out of the possible options? I chose this fix because it takes that `rack` gemfile back down to __2__ requests: `/versions` and `/info/rack`, as it should be, while maintaining proper searching for back-deps.
| * | | | | [Fetcher::Dependency] Avoid re-checking availability via network requestsseg-fix-fetcher-regressionSamuel Giddins2017-09-131-1/+1
| | | | | |
| * | | | | Dont consider deps pinned on 1.x if they dont have an explicit sourceSamuel Giddins2017-09-133-3/+7
| | | | | |
| * | | | | [SpecSet] Use full_name in #mergeSamuel Giddins2017-09-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | This means specs with a Gem::Platform can be compared to those with a platform string
| * | | | | Avoid request-bloat in double checking logicSamuel Giddins2017-09-136-40/+65
| | | | | | | | | | | | | | | | | | | | | | | | This avoids attempting to double-check in each source for gems that are _in the locally installed set of gems_, which could add hundreds or thousands of extra requests
| * | | | | [Resolver] cache whether lockfile_uses_separate_rubygems_sourcesSamuel Giddins2017-09-131-8/+7
| | | | | |
| * | | | | Add a way to assert that Artifice only gets certain requestsSamuel Giddins2017-09-131-0/+26
| | | | | |
| * | | | | [Index] Add a helper to return the names of all specsSamuel Giddins2017-09-131-0/+6
| | | | | |
| * | | | | Add bundle1 binstubSamuel Giddins2017-09-131-0/+8
| |/ / / /
* | | | | Auto merge of #6011 - bundler:indirect/expand-env, r=indirectThe Bundler Bot2017-09-132-10/+33
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | Expand `env` output We've been printing the version of OpenSSL that Ruby was compiled against, but not the version that was dynamically linked at runtime, which is a huge potential issue. While I was there, I added a few more things that seemed helpful.
| * | | | [Env] Ensure output is platform-appropriateSamuel Giddins2017-09-132-6/+7
| | | | | | | | | | | | | | | | | | | | Also, that everything is properly indented etc
| * | | | Expand `env` outputAndre Arko2017-09-131-8/+30
|/ / / /
* | | | Auto merge of #6025 - bundler:seg-spec-stub-warning, r=segiddinsThe Bundler Bot2017-09-111-1/+1
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | Avoid warning for stubbing `nil` since we now test what happens if `socket` is `nil`, and `rspec-mocks` warns when we do that
| * | | Avoid warning for stubbing `nil`Samuel Giddins2017-09-111-1/+1
|/ / /
View Lorry Controller Status