| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Remove uneeded files packaged into bunder's gem build on rubygems
What was the end-user problem that led to this PR?
--------------------------------------------------
I noticed while doing a `bundle open bundler` (inception!) that we have included the `bin/` directory in the packaged gem. While this is not hurting anything, it provides a bunch of scripts that won't function properly in any capacity when installed through ruby gems.
While doing that, I noticed that the dotfiles for CI were also packaged up in the gem, so I made sure to only include specific files from there that seemed to provide value when being shipped as a gem.
What is your fix for the problem, implemented in this PR?
---------------------------------------------------------
Change the reduction of the results from `git ls-files` to be a whitelist instead of a blacklist. This was to reduce the complexity of the regexp that would have resulted from change what directories to include, not ship CI files in the top level dir, while also still wanting to ship the `CHANGELOG.md`, `LICENSE.md`, and `README.md` files along with the build, since I think they do provide value being included with the packaged gem.
Why did you choose this fix out of the possible options?
--------------------------------------------------------
Some of the choices here were a bit subjective, especially what I decided on as "necessary" regarding the `.md` files that I included. Projects like rails went with these three, so I decided to use that as a base, but some might think that the `CHANGELOG.md` being included is a bit excessive and is a large file that most won't even read in this form, and I don't have a hard opinion one way or the other.
That said, I do think that developer files should not be packaged in the gem, and this precedent has already been set with the original blacklist, it just wasn't very complete. How I did it could probably be changed based on developer preference, but I tried to stay as true to what was already there before all else.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While not required for the build to function, they provide links and
information to developers who find themselves in the codebase of the gem
they have installed on their system.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `bin/` dir was getting included as part of the bundler release,
along with all of the files from the top level directory in the project,
most of which don't need to be there (CI config files mostly). Only the
`lib/` and `exe/` dirs are needed from git.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[CLI] Suggest bundle update --bundler when a newer version is installed
### What was the end-user problem that led to this PR?
The problem is once users start using our new `bin/bundle` binstub or the RubyGems that helps lock to the bundler version in the lockfile, the outdated bundler version warning was outdated.
### What was your diagnosis of the problem?
My diagnosis was we needed to tell people to `bundle update --bundler`, and restrict the `gem install` suggestion to when the latest version indeed wasn't installed.
### What is your fix for the problem, implemented in this PR?
My fix takes into account the actual installed bundler versions.
@indirect I think this addresses your concern on the RG PR?
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix a typos
This PR is a small change that fixed a typos in spec.
|
