summaryrefslogtreecommitdiff
path: root/lib/bundler/source
Commit message (Collapse)AuthorAgeFilesLines
* [Source::RubyGems] Allow installing when the path is `.`segiddins/6475-install-path-dotSamuel Giddins2018-04-081-1/+4
|
* [GitProxy] Fail gracefully when resetting to the given revision failssegiddins/fail-gracefully-when-resetting-to-rev-failsSamuel Giddins2018-03-101-1/+6
|
* [Source::RubyGems] Ensure the bindir exists before installingseg-fix-travis-ruby-2.5Samuel Giddins2018-01-151-0/+2
| | | | This will help avoid a potential race condition in RubyGems
* Stop overriding specs during double-checksAndre Arko2017-11-261-4/+2
| | | | | | This fixes my test-case reproduction of #6072. I’m pretty sure it’s because the double-check was overriding the locally installed index specs with specs fetched from the RubyGems API, causing Bundler to conclude that the gems aren’t installed, even though they are.
* Ensure that autoloads are resolved in the real working directorySamuel Giddins2017-10-291-0/+1
| | | | Fixes an issue on 2.5.0-dev where using local git overrides would cause an exception because the default bundler had been loaded
* Avoid activating stdlib digest under Ruby 2.5seg-ruby-2-5-digest-gemSamuel Giddins2017-10-222-3/+2
|
* Load digest subclasses in a thread-safe mannerseg-digest-loadingSamuel Giddins2017-10-152-3/+3
|
* Auto merge of #6010 - bundler:seg-remove-failed-gem-download, r=indirectThe Bundler Bot2017-09-151-2/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-061-2/+8
| |
* | Dont consider deps pinned on 1.x if they dont have an explicit sourceSamuel Giddins2017-09-131-1/+5
| |
* | Avoid request-bloat in double checking logicSamuel Giddins2017-09-131-1/+20
|/ | | | 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
* Completely remove the package --all option on 2.0 and force its behaviorseg-bundler-2-defaultsSamuel Giddins2017-08-282-2/+2
|
* Move cached extensions to cache/extensionsseg-globally-cache-built-extensionsSamuel Giddins2017-08-193-14/+11
|
* Cache git extensions in a path that includes the revSamuel Giddins2017-08-191-1/+1
|
* Globally cache built extensions for RG & Git sourcesSamuel Giddins2017-08-194-2/+19
|
* Allow to add username and password to a remote during a deploymentAdrian Gomez2017-08-022-6/+14
|
* [Source::Git] Cache repos globallyseg-globally-cache-git-reposSamuel Giddins2017-07-251-4/+4
|
* Auto merge of #5860 - bundler:seg-validate-settings, r=segiddinsThe Bundler Bot2017-07-252-4/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce the notion of settings validation & default install to ./.bundle 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... ### What was your diagnosis of the problem? My diagnosis was... ### What is your fix for the problem, implemented in this PR? My fix... ### Why did you choose this fix out of the possible options? I chose this fix because...
| * Update the specs for the default bundle path being ./.bundleSamuel Giddins2017-07-231-3/+1
| |
| * Default the install path to ./bundle in Bundler 2Samuel Giddins2017-07-231-1/+1
| |
* | Add a special bundler binstub that ensures the correct version is activatedSamuel Giddins2017-07-211-0/+2
|/
* Set forgotten command line options via config in 2.0Samuel Giddins2017-07-191-1/+1
|
* [RuboCop] Enable Layout/EmptyLineAfterMagicComment copKoichi ITO2017-07-167-0/+7
|
* Auto merge of #5817 - NickLaMuro:bug_with_path_gem_source_equivalency, ↵The Bundler Bot2017-07-051-1/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r=segiddins Compare sources using source's root ### What was the end-user problem that led to this PR? Given a setup where: 1. A project's Gemfile makes use of another project's Gemfile and the `eval_gemfile` method to share the dependencies. Something like: ```ruby # project_plugin's Gemfile eval_gemfile(File.expand_path("../../main_project/Gemfile", __FILE__)) ``` 2. The main project includes a path gem in it that is nested in the main project: ```ruby # main_project's Gemfile gem "foo_gem", :path => "vendor/foo_gem" ``` 3. A `bundle install` is followed by a `bundle install --deployment`, the second of which triggers a comparison of the `lockfile.sources` and the `Bundler.definition` A error will occur when comparing the specs, saying the the "foo_gem" source has been deleted: ```console $ bundle install ... $ bundle install --deployment You are trying to install in deployment mode after changing your Gemfile. Run `bundle install` elsewhere and add the updated Gemfile.lock to version control. the gemspecs for path gems changed You have deleted from the Gemfile: * source: source at `../main_project/vendor/foo_gem` ``` ### What was your diagnosis of the problem? (extracted from the commit message) When doing the following: expand(other.original_path) inside a `Bundler::Source::Path` instance, the `@root_path` from the instance that is having `eq?` called on it, the the `other` instance's `root_path`. This, in obscure cases, can cause a bug when you are doing an nested eval_gemfile or other calls when comparing the lockfile's locked path sources to the `Bundler.definition`'s path sources. ### What is your fix for the problem, implemented in this PR? Use a new public method, `Bundler::Source::Path#expanded_original_path`, in the `eq?` method instead of using's the instance's `#expand` method. ### Why did you choose this fix out of the possible options? (extracted from the commit message) Creating the `expanded_original_path` method allows a public interface to be made available (and doesn't mess with any exiting functionality) that allows comparing the source path of one `Source::Path`'s `expand_path` to another, where each uses their own `root_path` to resolve their full path, instead of sharing the base one and causing edge case bugs
| * Compare sources using source's rootNick LaMuro2017-06-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing the following: expand(other.original_path) inside a Bundler::Source::Path instance, the `@root_path` from the instance that is having eql? called on it, the other instance's root_path. This, in obscure cases, can cause a bug when you are doing an nested eval_gemfile or other calls when comparing the lockfile's locked path sources to the Bundler.definition's path sources. Creating the expanded_original_path method allows a public interface to be made available (and doesn't mess with any exiting functionality) that allows comparing the source path of one Source::Path's expand_path to another, where each uses their own root_path to resolve their full path, instead of sharing the base one and causing edge case bugs
* | Auto merge of #5790 - bundler:seg-suppress-using-messages, r=indirectThe Bundler Bot2017-07-054-4/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [2.0] Suppress `Using …` messages during installation when a version has not changed ### What was the end-user problem that led to this PR? The problem was that `bundle install` output can get very verbose, even when Bundler is not doing anything. See https://github.com/bundler/bundler-features/issues/33. ### Was was your diagnosis of the problem? My diagnosis was that bundler was printing a bunch of `Using name (version)` messages, even when we were already using that gem at the same version. ### What is your fix for the problem, implemented in this PR? My fix is to introduce a feature flag (enabled by default on 2.0), that will only print those extra `Using` messages when `--verbose` is passed, and will continue to print them when there was an old version we can tell users about. Note that we still print a message when installing a gem for the first time. ### Why did you choose this fix out of the possible options? I chose this fix because it was essentially what had been done in https://github.com/bundler/bundler/pull/3872, and allows for easy feature-flagging.
| * | Update the Bundler 2 specs for the removal of using... messagesseg-suppress-using-messagesSamuel Giddins2017-07-031-1/+1
| | |
| * | Suppress `Using …` messages during installation when a version has not changedSamuel Giddins2017-07-023-3/+3
| | |
* | | Vendor fileutils since it is now a gemSamuel Giddins2017-06-281-1/+1
|/ /
* | Auto merge of #5792 - bundler:seg-remove-rubygems-aggregate, r=segiddinsThe Bundler Bot2017-06-272-77/+101
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [2.0] Remove RubyGems Aggregate & support transitive source pinning ### What was the end-user problem that led to this PR? The problem was that the resolver could resolve specs from _any_ of the sources specified in the Gemfile, even if that source had nothing to do with the spec in question. This was such a large security vulnerability that, when discovered, it warranted a CVE and its own minor release of Bundler. Closes #3671. Closes #3696. Closes #4059. ### Was was your diagnosis of the problem? My diagnosis was that we needed to get rid of the notion of a `rubygems aggregate` and enforce that specs could only come either from the source they were declared to come from (the top-level source if declared at the top-level of the Gemfile, else a scoped source), or a source that it transitively "inherited" from the gems that required it. ### What is your fix for the problem, implemented in this PR? My fix is to disable multiple top-level sources in the Gemfile, remove the RubyGems aggregate, and filter the sources gems could come from as described above. ### Why did you choose this fix out of the possible options? I chose this fix because it allows doing the filtering in a reasonably performant manner, and refactors the way we handle sources to abstract some of the grossness in such a way that the machinations to make sure that all of the necessary gem info is downloaded is encapsulated into a single method, driven from the definition, rather than being specific to rubygems sources. See https://github.com/bundler/bundler/pull/4714 and https://github.com/bundler/bundler/pull/4930 for the prior implementation.
| * | More bundler 2 spec fixesseg-remove-rubygems-aggregateSamuel Giddins2017-06-271-0/+2
| | |
| * | Fix plugin installation when the plugin depends upon BundlerSamuel Giddins2017-06-231-1/+5
| | |
| * | Always serve the Bundler gemspec from the metadata sourceSamuel Giddins2017-06-232-27/+29
| | |
| * | Consolidate the double-checking logicSamuel Giddins2017-06-231-48/+14
| | |
| * | Avoid fetching the full index to get all dependency namesSamuel Giddins2017-06-231-2/+2
| | |
| * | Implement source pinning for 2.0Samuel Giddins2017-06-232-2/+52
| |/
* | Put the global gem cache behind a feature flagSamuel Giddins2017-06-271-0/+1
| |
* | Add specs for the global gem cacheSamuel Giddins2017-06-271-1/+0
| |
* | Globally cache downloaded .gem filesSamuel Giddins2017-06-271-2/+66
| |
* | Extract md5 checking to SharedHelpersSamuel Giddins2017-06-271-0/+2
|/
* [Source::Git] Print the underlying error when falling back to cached git dataSamuel Giddins2017-06-231-2/+2
|
* Filter git credentials when a revision is missingSamuel Giddins2017-06-231-1/+1
|
* Eval Gemfiles one fewer time when running `bundle install`seg-reduce-gemfile-eval-countSamuel Giddins2017-06-142-0/+3
|
* [GitProxy] Don't declare Git as a subclass twiceSamuel Giddins2017-05-291-1/+1
|
* [RuboCop] Enable Style/PercentLiteralDelimitersKoichi ITO2017-05-281-2/+2
| | | | Run `rubocop -a --only Style/PercentLiteralDelimiters` and `rubocop --auto-gen-config`.
* [GitProxy] Force deinitializing submodulesseg-force-submodule-deinitSamuel Giddins2017-05-231-1/+1
|
* Unify the notation of RubyGemsKoichi ITO2017-05-041-1/+1
|
* Auto merge of #5624 - bundler:seg-fetch-named-symbolic-refs, r=indirectThe Bundler Bot2017-04-301-8/+11
|\ | | | | | | | | | | | | | | | | | | | | [Git] Allow specifying non-branch symbolic refs > The intention here is to allow installing a gem from git using a > ref of the form "refs/zuul/" (which are used by the zuul > continuous-integration system). There are likely other use cases for > arbitrary refs. Closes #4845
| * [Git] Allow specifying non-branch symbolic refsseg-fetch-named-symbolic-refsSamuel Giddins2017-04-281-8/+11
| |
* | [Git] Only shorten refs if they are SHAsseg-shortref-displaySamuel Giddins2017-04-281-2/+6
|/
View Lorry Controller Status