| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix bundle binstubs stanadlone flag
### What was the end-user problem that led to this PR?
Currently, specifying the `--standalone` flag breaks `bundler binstubs` unless you have the `path` setting set in your bundle config. This is breaking in different ways but mostly for the same reason.
Bundler Master:
```
RuntimeError: Can't standalone without an explicit path set
/Users/c/Desktop/Projects/bundler/lib/bundler/installer.rb:158:in `generate_standalone_bundler_executable_stubs'
/Users/c/Desktop/Projects/bundler/lib/bundler/cli/binstubs.rb:36:in `block in run'
/Users/c/Desktop/Projects/bundler/lib/bundler/cli/binstubs.rb:26:in `each'
```
Bundler 1.15.4:
```
TypeError: no implicit conversion of nil into String
/Users/c/.rubies/ruby-2.4.1/lib/ruby/2.4.0/pathname.rb:409:in `initialize'
/Users/c/.rubies/ruby-2.4.1/lib/ruby/2.4.0/pathname.rb:409:in `new'
/Users/c/.rubies/ruby-2.4.1/lib/ruby/2.4.0/pathname.rb:409:in `join'
/Users/c/.gem/ruby/2.4.1/gems/bundler-1.15.4/lib/bundler/installer.rb:142:in `generate_standalone_bundler_executable_stubs'
```
This was not caught in our tests because the `--standalone` flag was infact not being tested.
Another issue is that we have command options for the `bundle binstubs` command which are missing documentation in the man pages.
### What was your diagnosis of the problem?
This error occurs when the `path` setting is not set which `generate_standalone_bundler_executable_stubs` expects to be set
### What is your fix for the problem, implemented in this PR?
Set a temporary path setting in the binstubs command of either any currently set `path` setting or use `Bundler.root` instead.
### Why did you choose this fix out of the possible options?
This was the most simplest solution that i can think of without having to change the standalone binstub generator.
|
| | |
| |
| |
| |
| | |
Also move the bundler-install standalone flag tests into the the bundle
install tests
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the locked bundler is under 2.0, allow any version < 2
### What was the end-user problem that led to this PR?
The problem was the bin stub would lock to a specific version even for a 1.x version, which was an incompatible change.
See @indirect's comment in https://github.com/rubygems/rubygems/pull/1977#issuecomment-322852799
### What was your diagnosis of the problem?
My diagnosis was we needed to only pin to a specific version for 2.0+.
### What is your fix for the problem, implemented in this PR?
My fix transforms any 1.x bundler version to a "< 2" constraint.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Update] Avoid a normal update when running with only --bundler
### What was the end-user problem that led to this PR?
The problem was `bundle update --bundler` went through the full update/resolution path when really we just want to pin to a different bundler version.
### What was your diagnosis of the problem?
My diagnosis was we should just update the lockfile, without threading the rest of the process like an update.
This implements what @indirect requested in https://github.com/rubygems/rubygems/pull/1977#issuecomment-322852799.
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Avoid namespace pollution
fixes #5958.
### What was the end-user problem that led to this PR?
The problem was that local variables are magically introduced into the global toplevel, when there is a local gemspec that has such local variables.
### What was your diagnosis of the problem?
My diagnosis was that `TOPLEVEL_BINDING` is used with `eval`
### What is your fix for the problem, implemented in this PR?
My fix is to duplicate that binding.
### Why did you choose this fix out of the possible options?
I chose this fix because it is clean and concise. Other possible options are like reinventions of wheel.
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
Evaluating user inputs in the TOPLEVEL_BINDING can pollute global
toplevel local variable namespace because there is only one
TOPLEVEL_BINDING across the entire process. Here in this method
we do not need such thing. Duplicating that binding to create
dedicated one for this purpose should effectively kill such global
side effects.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ensure deprecations become a hard error in Bundler 2
### What was the end-user problem that led to this PR?
The problem was some deprecations aren't guaranteed to be behind a feature flag, so we want to guarantee that we won't continue to support those behaviors when they're intended to be removed.
### What was your diagnosis of the problem?
My diagnosis was we needed to ensure that deprecations don't stay deprecations past the point they're supported.
### What is your fix for the problem, implemented in this PR?
My fix adds a `major_version` argument to the deprecation method, and raises an error if the current version is `>=` that version
### Why did you choose this fix out of the possible options?
I chose this fix because it will ensure that everything deprecated won't continue to work past when it's supposed to, reducing the chance we'll need to accidentally support things we won't want to.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| | |
Version 1.15.4
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
(cherry picked from commit da6a52a9b255147b389d29e2b22ce397bbb8377b)
# Conflicts:
# lib/bundler/cli/pristine.rb
# spec/commands/pristine_spec.rb
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Upgrade thor to 0.20.0
Thor 0.20.0 was released so I'm upgrading bundler to the newest version.
(cherry picked from commit 1f4e890304a5dae7c83d40305e2d878ca7c0362e)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
exit if bundle bin path contains a path separator
fixes #5485
### What was the end-user problem that led to this PR?
Bundler does not work with paths that contain the path separator.
### What was your diagnosis of the problem?
The ```bundle_bin``` path can't contain a path separator.
### What is your fix for the problem, implemented in this PR?
We can validate the ```bundle_path``` to make sure that it does not contain the
current ```File::PATH_SEPARATOR```. If we find the path separator, we exit with a non-zero
code and give the user an error message.
### Why did you choose this fix out of the possible options?
I chose this fix because it was recommended by @colby-swandale.
(cherry picked from commit 605beb0a4800c923380f2dfe903f2fd2eee8b7c5)
# Conflicts:
# lib/bundler/shared_helpers.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Retry downloading gems consistently across all versions of RubyGems
### What was the end-user problem that led to this PR?
`Gem::RemoteFetcher::FetchError` failures were not being retried when downloading gems. Retrying downloading of gems for network blips is very ideal and helpful in CI environment.
### What was your diagnosis of the problem?
- The retry logic that existed (using `Bundler::Retry`) for `Bundler::RubygemsIntegration#download_gem` was not getting called, becase `Bundler.rubygems` defaulted to a sub class of `Bundler::RubygemsIntegration::MoreFuture`, which inherited from `Bundler::RubygemsIntegration::Future` and `#download_gem` in there didn't perform download with retry logic.
- Sending `Gem::RemoteFetcher::FetchError` as an argument to `Bundler::Retry` meant, `Bundler::Retry` would fail first thing,[ if exception being raised was the one being supplied](https://github.com/bundler/bundler/blob/5a61b65ad5ec1df1539ecf8bc5d124f2b254ba14/lib/bundler/retry.rb#L46..L49). The intent is to retry when downloading fails.
**Example of how sub classing issue looked like:**
```ruby
class RubygemsIntegration
def download_gem
"I retry when downloading"
end
end
class Future < RubygemsIntegration
def download_gem
"I don't retry when downloading"
end
end
class MoreFuture < Future
# no download_gem
end
mf = MoreFuture.new #=> Bundler.rubygems where RubyGem version is > 2.1.0
mf.download_gem
=> "I don't retry when downloading"
```
**Example of Bundler::Retry**
```ruby
Bundler::Retry.new("download gem from", StandardError).attempts do
puts "I will only print once, whereas I should print 4 times"
raise StandardError.new("FooBar")
end
```
### What is your fix for the problem, implemented in this PR?
I added the retry logic for to `Bundler::RubygemsIntegration::Future#download_gem` and removed `Gem::RemoteFetcher::FetchError` as an argument for failed exceptions.
### Why did you choose this fix out of the possible options?
I chose this fix because this fix fulfills the expected behavior(https://github.com/bundler/bundler/issues/4846). Also added specs that makes sure retry logic is intact, which otherwise would have failed without the current logic in place.
(cherry picked from commit c14d59a29739ea1a4bb73f664fc6620a711250b0)
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
[2.0] Add a compatibility guard that prints friendly errors on bundler 2+
This way, if someone manages to get bundler 2 installed on a system we don't support, they'll get a very obvious message saying so
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
# Conflicts:
# spec/install/bundler_spec.rb
# spec/other/compatibility_guard_spec.rb
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
https://github.com/bundler/bundler/issues/5789
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[2.0] Globally cache built extensions for RG & Git sources
### What was the end-user problem that led to this PR?
The problem was with the switch to defaulting the install path to `./.bundle`, you'd need to rebuild extensions for each app you use a gem in.
Closes #5905
### What was your diagnosis of the problem?
My diagnosis was we could globally cache built extensions in a per-ruby, per-source directory, similar to how 2.0 global `.gem` caching and the git cache works.
### What is your fix for the problem, implemented in this PR?
My fix implements that cache.
### Remaining questions:
- [x] Tests
- [x] Right now, the directory structure is `cache/gems/remote_name/extensions/ruby_scope/gem_full_name`. I'm wondering whether we should make it `cache/extensions/ruby_scope/source_slug/gem_full_name` instead to make removing the cache for an old ruby version easier?
- [x] Should the cache path include something about the local OS? ie. do we want to force a re-compile when the user updates OS versions?
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use universal rubygems method for installing gems
What was the end-user problem that led to this PR?
--------------------------------------------------
When following the [setup documentation](https://github.com/bundler/bundler/blob/master/doc/development/SETUP.md) for bundler, it suggests to run `bin/rake spec:deps` to install the development dependencies for bundler.
Doing this with ruby 1.9.3 (and not upgrading rubygems) will cause this to fail.
What was your diagnosis of the problem?
---------------------------------------
Ruby 1.9.3 ships with a version of rubygems that is less than 2.0, and doesn't include the mechanisms for installing multiple gems (with specific versions) using colon delimited strings (which is the mechanism used to do so in `spec:deps`).
What is your fix for the problem, implemented in this PR?
---------------------------------------------------------
By using `ruby -S gem install [GEM_NAME] -v [GEM_VERSION]` for each gem, it is a universal way of installing targeted versions of gems on various versions of ruby/rubygems that isn't rubygems dependent.
Why did you choose this fix out of the possible options?
--------------------------------------------------------
This was the easiest implementation to do that maintains the same documentaion and instructions necessary to setup bundler for development.
The cons with this approach is that is causes additional subshell invocations to be launched for each gem, instead of one, which will be slower. Since this is a finite number of calls we are doing this for (5 currently), I expect that to be negligible compared to the total time necessary load up the rubygems `gem` command and fetch each gem from rubygems (we can compare the travis builds from master to see this to compare).
An alternative to this approach would be to call out to the `Gem::Installer` directly from within the rake task, and avoid calling out to the `gem` command all together. This has the downside of requiring more code to do it, but should alleviate the any extra time caused by using `sh` call to install the gems (might try this in a separate commit so it will have another build on travis and we can compare that result to the initial implementation).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The current implementation for installing gems via `rake spec:deps`
builds a rubygems command that includes all of the gems in a single
oneliner with gem names and versions that are colon delimited:
$ ruby -S gem install --no-ri --no-rdoc --conservative 'automatiek:~> 1.0.0' 'mustache:0.99.6' ...
This functionality does not exist prior to rubygems 2.0, so this will
not function with the rubygems that ships with ruby 1.9.3
Splitting this into individual `ruby -S gem install` calls for rubygems
versions prior to 2.0, and using the `-v` flag allows this to function
on older implemetations.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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).
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Upgrade thor to 0.20.0
Thor 0.20.0 was released so I'm upgrading bundler to the newest version.
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use ssl client cert and ca cert settings from gem configuration as fallbacks
### What was the end-user problem that led to this PR?
The problem was having to configure ssl client cert and ca cert in bundler and gem.
### What is your fix for the problem, implemented in this PR?
My fix makes bundler check the gem configuration for these settings.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes sense for the user to only configure these once.
Couldn't find existing coverage for this in the tests so haven't added any...
Also assume a changelog entry is needed but can't see a unreleased changes section so not sure how this is handled.
|
