| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
Use Bundler::Installer for bundle pristine
Fixes bundler pristine to respect the `bundle config` options for particular gems. In my particular case, on OSX I have a keg version of `pg` and a bundle config with the following entry:
```console
$ bundle config
...
build.pg
Set for the current user (/Users/nicklamuro/.bundle/config): "--with-pg-config=/usr/local/Cellar/postgresql@9.5/9.5.6/bin/pg_config"
```
This would not be respected
What was the end-user problem that led to this PR?
--------------------------------------------------
See above, but steps to reproduce (requires `bundler` >= 1.15):
1. Install postgres on your machine if it is not already there (OS dependent)
2. Add the following bundler build arg for `pg`:
```console
$ bundle config build.pg -- --with-pg-config=$(which pg_config)
```
2. Make sure `pg_config` is not in your `$PATH`:
```console
$ export PATH=$(echo "$PATH" | sed "s|:$(dirname $(which pg_conf)))||")
```
* Create a simple project with `pg` as a single gem in your Gemfile:
```
# Gemfile
gem "pg"
```
* Bundle:
```console
$ bundle install
```
* Attempt to `bundle pristine` (you should get an error):
```console
$ bundle pristine
```
What was your diagnosis of the problem?
---------------------------------------
The newly added `bundle pristine` did no use the same code that was used by `bundle install` to execute the re-installation of the gem.
What is your fix for the problem, implemented in this PR?
---------------------------------------------------------
By making use of the `Bundler::Installer` and `Bundler::Installer::GemInstaller` code that is already used with `bundle install`, we can reuse the code that injects the `bundle config` options into each gem that is being installed.
Why did you choose this fix out of the possible options?
--------------------------------------------------------
Didn't want to repeat code that was already being used elsewhere. Caused a few lines of code to be added that weren't there previously, but nothing obscene.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using a combination of Bundler::Installer and Bundler::GemInstaller to
install the gems in `bundle pristine` allows the code for making use of
bundler config being respected to be reused when installing a gem.
Makes use of the compiled Makefile for c-extensions to confirm that the
args are passed properly (honestly... a little hacky, but no real other
way to do this on older versions of rubygems).
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid Range Not Satisfiable errors during normal request flow
### What was the end-user problem that led to this PR?
Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](https://github.com/rubygems/rubygems.org/pull/1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing.
Closes #5373.
### What was your diagnosis of the problem?
See above
### What is your fix for the problem, implemented in this PR?
This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it.
### Why did you choose this fix out of the possible options?
An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Also ensure the resolver processes specs in the correct order for error messages
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
remove forbidden chars in cassettes pathname
### What was the end-user problem that led to this PR?
Users running Micorsoft Windows are currently unable to clone to Bundler project due to a forbidden character in the folder path:
`spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/api/v1/dependencies?gems=bundler'`
The `?` being the forbidden character.
See #5828
### What is your fix for the problem, implemented in this PR?
Replaced the forbidden character in the folder name with a `-` and updated the VCR spec helper to replace any forbidden character with a `-` in the filename function.
### Why did you choose this fix out of the possible options?
This was the most simple approach to fix the issue.
|
| | | |
|
| |/
|/| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[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.
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
content-length headers
|
| |
|
| |
|
| |
|
|
|
|
| |
Run `rubocop -a --only Style/PercentLiteralDelimiters` and `rubocop --auto-gen-config`.
|
|
|
|
|
| |
See https://github.com/rack/rack/issues/1168
The above issue broke rack on 1.9.3
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Fail gracefully when installing a spec where the API is missing deps
Fixes https://github.com/bundler/bundler/issues/5426
Closes https://github.com/bundler/bundler/issues/5339
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Don't read global settings on a read-only FS with no $HOME
Closes https://github.com/bundler/bundler/issues/5371
This is an alternative to https://github.com/bundler/bundler/pull/5385
|
| |
| |
| |
| |
| | |
This was, modifications to the temporary directory are blown away
between each test and don't clutter the user's FS
|