| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Warn when making an outdated TLS connection to rubygems.org
Right now, output looks like
```
Your Ruby version does not support TLSv1.1 or newer, which will be required to connect to https://index.rubygems.org by June 2018.
Fetching gem metadata from https://rubygems.org/...........
Fetching version metadata from https://rubygems.org/..
Resolving dependencies...
Using rake 11.3.0
Using automatiek 0.1.2 from source at `.`
Using rspec-support 3.5.0
Using diff-lcs 1.3
Using bundler 1.15.0.pre.3
Using rspec-core 3.5.4
Using rspec-expectations 3.5.0
Using rspec-mocks 3.5.0
Using rspec 3.5.0
Bundle updated!
```
Obviously this requires tests, and also backing out forcing the TLS version (which I did to make testing easier). The message could also use improvement, but I figured I'd ask for input from @indirect and @dwradcliffe
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Default to packaging all on 2.0
This is going to be the last set of changes to defaults in Bundler 2.
@colby-swandale @indirect are there other changes I should be making here?
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update Molinillo to 0.6.2
### What was the end-user problem that led to this PR?
The problem was Molinillo 0.6.2 fixes a potential problem.
### What is your fix for the problem, implemented in this PR?
My fix is to update to Molinillo 0.6.2.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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?
|
