summaryrefslogtreecommitdiff
path: root/lib/bundler
Commit message (Collapse)AuthorAgeFilesLines
* add feature flag to use https for :git in the dslcolby/git-https-defaultColby Swandale2018-11-252-1/+3
|
* Merge #6790Bundlerbot2018-11-172-9/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6790: Fix multiple source warning messages from `error` to `warn` r=greysteil a=jlw ### What was the end-user problem that led to this PR? I've been working on a few repos for most of this year that use a privately-hosted gem with the same name (but completely different purpose) as a gem hosted at rubygems.org - whenever I start with a clean copy and `bundle install` for the first time, I am presented with a warning in red that the gem was found in multiple sources. The red text makes me think that something went wrong, even though bundler did exactly what I wanted it to do. The user experience is wrong - a warning should not be red. ### What was your diagnosis of the problem? When I looked at the source, I saw immediately that the warning was using `Bundler.ui.error` instead of `Bundler.ui.warn`. This is a bug fix with a limited lifespan - after setting up a local copy of bundler I see that 2.0's handling of multiple sources A) is smarter and bypasses the error in most of the repos where I saw it with bundler 1.x; and B) fails early with a different error message in the remaining repos. ### What is your fix for the problem, implemented in this PR? The fix is simply switching to `Bundler.ui.warn` in this case. ### Why did you choose this fix out of the possible options? _I didn't see any other possible options._ Co-authored-by: Jeremy Weathers <jeremy@codekindly.com>
| * Fix multiple source warning messages from `error` to `warn`Jeremy Weathers2018-11-162-9/+10
| |
* | Merge #6775Bundlerbot2018-11-161-1/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6775: [Plugin::Index] Only register each plugin once for a given hook r=colby-swandale a=segiddins ### What was the end-user problem that led to this PR? The problem was running `plugin install` twice for a plugin withs hooks would cause that hook to be registered twice. Closes #6771. ### What was your diagnosis of the problem? My diagnosis was a plugin's hooks should only be run once per event. ### What is your fix for the problem, implemented in this PR? My fix is to `uniq` the list of plugins registered for each event. Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com> Co-authored-by: Colby Swandale <me@colby.fyi>
| * | [Plugin::Index] Only register each plugin once for a given hookSamuel Giddins2018-11-051-1/+4
| | |
* | | Merge #6743Bundlerbot2018-11-161-3/+13
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6743: Support file structure of ruby core repository. r=hsbt a=hsbt ### What was the end-user problem that led to this PR? In the ruby core repository, I put bundler executable and bundler libraries under the `bin` and `lib` directories. It breaks the current behavior. ### What is your fix for the problem, implemented in this PR? Support the structure of ruby core repository. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | rubocop -aSHIBATA Hiroshi2018-10-201-3/+3
| | |
| * | Added to support BUNDLE_RUBY and BUNDLE_GEM environmental variables.SHIBATA Hiroshi2018-10-201-3/+7
| | | | | | | | | | | | They are replaced build binary on ruby core repository.
| * | Fixed existence example.SHIBATA Hiroshi2018-10-201-1/+1
| | |
| * | rubocop -aSHIBATA Hiroshi2018-10-201-6/+4
| | |
| * | Support file structure of ruby core repository.SHIBATA Hiroshi2018-10-201-4/+12
| | |
* | | Fix indentation of bundler executablemeganemura2018-11-061-1/+1
| |/ |/|
* | Merge #6769Bundlerbot2018-10-301-7/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6769: Fix `remove` when block method appears in gem name r=segiddins a=dduugg 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? https://github.com/bundler/bundler/issues/6768 ### What was your diagnosis of the problem? `remove_nested_blocks` considers any appearance of text matching a block method (`group source env install_if`) to be an occurrence of a nested block. ### What is your fix for the problem, implemented in this PR? `remove_nested_blocks` should only reduce the scope of where a nested block method can occur. ### Why did you choose this fix out of the possible options? Another approach would use word delimiters rather than `starts_with?` to find nested block methods, but this is probably fine. Co-authored-by: Douglas Eichelberger <dduugg@gmail.com>
| * | Fix error when gem name includes block method nameDouglas Eichelberger2018-10-291-7/+7
| | |
* | | Remove more unnecessary stuffremove_old_rubygems_stuff_from_specsDavid Rodríguez2018-10-261-11/+4
|/ /
* | Merge #6737Bundlerbot2018-10-201-6/+11
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6737: when running from source, find submodule shas too r=indirect a=indirect We recently merged #6664 to prevent Bundler from (wrongly) claiming the git commit of any parent directory when it is run from source. However, Bundler is also run from source as a submodule in RubyGems, and in that case it does not have its own git directory. This commit resolves the failure in version_spec.rb that only appears when the Bundler tests are run from a submodule, by explicitly checking for that submodule, and using `git ls-tree` to get the sha if so. Arguably, this is a bugfix compared to the previous behavior, which would blindly print the current sha from the _RubyGems_ repo, while claiming that it was the sha of Bundler. Co-authored-by: Andre Arko <andre@arko.net>
| * avoid dependency on awkAndre Arko2018-10-201-1/+1
| |
| * return to avoid double-settingAndre Arko2018-10-201-2/+2
| |
| * when running from source, find submodule shas tooindirect/bundler-submodule-shasAndre Arko2018-10-121-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We recently merged #6664 to prevent Bundler from (wrongly) claiming the git commit of any parent directory when it is run from source. However, Bundler is also run from source as a submodule in RubyGems, and in that case it does not have its own git directory. This commit resolves the failure in version_spec.rb that only appears when the Bundler tests are run from a submodule, by explicitly checking for that submodule, and using `git ls-tree` to get the sha if so. Arguably, this is a bugfix compared to the previous behavior, which would blindly print the current sha from the _RubyGems_ repo, while claiming that it was the sha of Bundler.
* | Merge #6749Bundlerbot2018-10-192-13/+33
|\ \ | | | | | | | | | | | | | | | | | | | | | 6749: Add local git repository source option (`--local_git`) to plugin installation r=indirect a=indirect Reopening #6338 to close #5446. Co-authored-by: Saverio Miroddi <saverio.pub2@gmail.com>
| * | Improve Cli::Plugin help, according to review notesaveriomiroddi-sav-install_plugin_from_file_supportSaverio Miroddi2018-04-211-1/+1
| | | | | | | | | | | | See https://github.com/bundler/bundler/pull/6338#discussion_r183209481.
| * | More solid options checking in Plugin::InstallerSaverio Miroddi2018-03-271-1/+1
| | | | | | | | | | | | Addresses https://github.com/bundler/bundler/pull/6338#discussion_r177393334.
| * | Rename `local-git` plugin install option to `local_git`Saverio Miroddi2018-03-272-5/+5
| | | | | | | | | | | | Addresses https://github.com/bundler/bundler/pull/6338#discussion_r177392401.
| * | Improve a comment in Plugin::Installer as referred by the language quality UTSaverio Miroddi2018-03-191-1/+1
| | |
| * | Workaround a Rubocop issue (assumed a bug) in Plugin::InstallerSaverio Miroddi2018-03-191-0/+5
| | |
| * | Plugin install description: restore to single lineSaverio Miroddi2018-03-191-7/+1
| | | | | | | | | | | | Thor squashes adjacent lines into a single one, so the previous long description prints in a single line.
| * | Rename plugin install --file option to --local-gitSaverio Miroddi2018-03-192-5/+5
| | |
| * | Plugin installer: make remote and local git source options mutually exclusiveSaverio Miroddi2018-03-191-0/+18
| | |
| * | Apply Rubocop required changes to Plugin::InstallerSaverio Miroddi2018-03-191-7/+2
| | |
| * | Refactor Plugin::Installer to have the original structure, with cleaner codeSaverio Miroddi2018-03-191-23/+32
| | | | | | | | | | | | | | | | | | | | | | | | The test suite is strict/intrusive, due to mocking private methods, and when the Installer structure is refactored, it's not clear where it fails. This refactoring returns to the original structure, while applying a refactoring that makes it clear what's happening, and easy to extend.
| * | Apply review note about Plugin::Installer#extract_sources_from_optionsSaverio Miroddi2018-03-181-19/+10
| | |
| * | Bundler::Plugin::Installer: remove the obsolete (and unneeded) URI.escapeSaverio Miroddi2018-03-111-2/+1
| | | | | | | | | | | | URI.escape is officially obsolete, and the Git source supports file paths anyway.
| * | Add file path source option (`--file`) to plugin installationSaverio Miroddi2018-03-112-1/+15
| | | | | | | | | | | | | | | | | | Convenience option for installing plugins from a local repository, using the local path: bundle plugin install --file /path/to/bundler-dependency_graph bundler-dependency_graph
| * | Refactor Bundler::Plugin::InstallerSaverio Miroddi2018-03-111-31/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core of the refactoring is to separate the main operations applied: - destructive operation performed on options - source list creation, from different sources - merge the common logic (in particular, the definition creation) This step is quite important for adding new source options (`file`), since the general idea was not easy to follow.
* | | Enable gemfile flag for bundle lockLaura Paakkinen2018-10-181-0/+2
| | |
* | | Remove the duplicate gems from suggestionsyuuji.yaginuma2018-10-151-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the lock file has the same gems for different platforms, the suggestion includes all those gems. For example, using the Rails's lock file(https://github.com/rails/rails/blob/4a51cbba58435bbba65ca50670bd6ae4887942bd/Gemfile.lock), it shows like this: ``` $ bundle update mai Could not find gem 'mai'. Did you mean ffi, ffi, ffi, ffi, mail, ast, jwt, que or wdm? ``` Since it is unnecessary to include the same gem, removed duplicate gems.
* | Check for file or folder when checking for git hash in build metadatacolby/fix-rubygems-spec-suiteColby Swandale2018-10-111-1/+3
| |
* | Merge #6718Bundlerbot2018-10-061-1/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6718: Correct `bundle show` deprecation r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was `bundle show` deprecation messages are incorrect: ``` $ bundle show yard [DEPRECATED FOR 2.0] use `bundle list` instead of `bundle show` Resolving dependencies... /home/deivid/Code/activeadmin/.bundle/ruby/2.5.0/gems/yard-0.9.16 $ bundle list yard ERROR: "bundle list" was called with arguments ["yard"] Usage: "bundle list" ``` ### What was your diagnosis of the problem? My diagnosis was that deprecation messages only mention `bundle list`, but in some cases, the replacement is `bundle info`. ### What is your fix for the problem, implemented in this PR? My fix is to replace "show" in the original command with the appropriate alternative in each case. ### Why did you choose this fix out of the possible options? I chose this fix because it was the most user friendly message, since it prints the exact command the user needs to type to get rid of the warning. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Refactor initial codecorrect_bundle_show_deprecationDavid Rodríguez2018-10-011-7/+5
| | |
| * | Fix `--paths` argument handlingDavid Rodríguez2018-10-011-1/+9
| | |
| * | Fix "bundle show" deprecation messagesDavid Rodríguez2018-10-011-1/+9
| | | | | | | | | | | | | | | With a single gem, it will be replaced by `bundle info`, not by `bundle list`.
* | | Merge #6711Bundlerbot2018-10-061-1/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6711: Avoid fetching an rebuilding git gems when it's not necessary r=segiddins a=casperisfine Kind of a followup to https://github.com/bundler/bundler/pull/4272 ### The issue As demonstrated by the updated test case, whenever a gem is changed (even a non-git one), bundler re-fetch all git gems, and recompile their extensions (if any). You can repro that issue by running the modified `git_spec.rb` against master. ### The proposed fix In that patch I simply make `Source::Git` skip the `fetch` step if the `cached_revision` matches the install path. Since `install_path` uses only the first 10 characters of the full revision, there is a very very small chance of a collision happening, but It's so small that I think it can be ignored. However my understanding of the codebase is too limited to be 100% sure the git gem would be properly updated if it's definition (`branch` / `ref` / `etc`) is updated. I tried to write a test case for this but couldn't figure out how to create a repo with multiple revisions. I'll keep digging, but I figured I might as well ask for feedback at this stage. @segiddins any thoughts on this ? (since you fixed #4272), any pointers on how to better test this? cc @rafaelfranca @jules2689 Co-authored-by: Jean Boussier <jean.boussier@gmail.com> Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
| * | | Add another spec, separate new case into its own testSamuel Giddins2018-10-021-1/+1
| | | |
| * | | Avoid fetching an rebuilding git gems when it's not necessaryJean Boussier2018-09-271-1/+5
| | | |
* | | | Merge #6687Bundlerbot2018-09-301-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6687: Fix assignment in condition. r=colby-swandale a=voxik I am not sure what is the purpose of this code neither I have idea if the proposed fix is actually correct, but I am quite sure that the condition does not make sense, because the assignment takes priority and therefore the branch is never accessible. So I just take a guess and submitted this PR to open the discussion ;) Please note this was pointed out by Coverity scan of the Bundler code: ~~~ Error: DEADCODE (CWE-561): rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". Now the type of "nil && Bundler.rubygems().loaded_specs("bundler")" must be null. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: assignment: Assigning: "loaded_spec" = "nil && Bundler.rubygems().loaded_specs("bundler")". rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: possible_types: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the type of "loaded_spec" must be null. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: implied_false: "nil" implies that the truth value of "nil" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". The truth value of "nil && Bundler.rubygems().loaded_specs("bundler")" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: truth: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the truth value of "loaded_spec" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_condition: The condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))" cannot be true. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_line: Execution cannot reach the expression "idx << loaded_spec" inside this statement: "(loaded_spec = (nil && Bund...". # 20| s.loaded_from = File.expand_path("..", __FILE__) # 21| end # 22|-> if loaded_spec = nil && Bundler.rubygems.loaded_specs("bundler") # 23| idx << loaded_spec # this has to come after the fake gemspec, to override it # 24| elsif local_spec = Bundler.rubygems.find_name("bundler").find {|s| s.version.to_s == VERSION } ~~~ Co-authored-by: Vít Ondruch <vondruch@redhat.com>
| * | | Fix assignment in condition.Vít Ondruch2018-09-251-1/+1
| | | |
* | | | make `only_update_to_newer_versions` work correctly with `bundle update`Florian Munz2018-09-251-2/+2
| |/ / |/| |
* | | Merge #6686Bundlerbot2018-09-251-5/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6686: Output OpenSSL information only when OpenSSL is available. r=segiddins a=voxik It seems that only single OpenSSL availability check should be enough to output or not output the OpenSSL information. I split this into two commits, so you can cherry-pick, in case you want to be more cautious about the availability of specific constants, but since they were introduced in Ruby 1.8.0 (https://github.com/ruby/ruby/commit/78ff3833fb67c8005a9b851037e7), I would not bother. Please note that that this code was pointed out by Coverity scanner (although it is definitely not an error): ~~~ Error: FORWARD_NULL (CWE-476): rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:113: null_check: Calling "defined?(OpenSSL)" implies that "OpenSSL" might be null-like. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:114: property_access: Accessing a property of null-like value "OpenSSL". # 112| out << [" Bin Dir", Gem.bindir] # 113| out << ["OpenSSL"] if defined?(OpenSSL) # 114|-> out << [" Compiled", OpenSSL::OPENSSL_VERSION] if defined?(OpenSSL::OPENSSL_VERSION) # 115| out << [" Loaded", OpenSSL::OPENSSL_LIBRARY_VERSION] if defined?(OpenSSL::OPENSSL_LIBRARY_VERSION) # 116| out << [" Cert File", OpenSSL::X509::DEFAULT_CERT_FILE] if defined?(OpenSSL::X509::DEFAULT_CERT_FILE) ~~~ Co-authored-by: Vít Ondruch <vondruch@redhat.com>
| * | | Output OpenSSL information only when OpenSSL is available.Vít Ondruch2018-09-061-5/+7
| |/ /
* | | Make the equivalent change to `bundle update`David Rodríguez2018-09-181-1/+2
| | |
View Lorry Controller Status