| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Check if source responds to `#remotes` before printing gem install error message
### What was the end-user problem that led to this PR?
There is a bug that was introduced in #6211 that prints an error message during `bundle install` if a gem failed to be installed. The error message attempts to call the `#remotes` method on `Bundler::Source::Git` which it does not implement.
### What was your diagnosis of the problem?
See #6563
### What is your fix for the problem, implemented in this PR?
Check if the `source` responds to `#remotes` before and return early
### Why did you choose this fix out of the possible options?
This seems to be the most simplest fix without having to refactor a lot of code.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't fallback to tempdir when required directories exist.
### What was the end-user problem that led to this PR?
When running Omnibus packaged software with updated bundler, a warning is displayed because the home folder is not owned by the user:
```
`/var/opt/gitlab` is not writable.
Bundler will use `/tmp/bundler/home/root' as your home directory temporarily.
```
There are valid reasons why this is desired, and I don't have control over it. What I can do is create the required folders used by bundler and provide them with the right permissions.
See https://github.com/bundler/bundler/issues/6546
### What was your diagnosis of the problem?
In practice instead of asking for permission on a higher level, if required folders are present and they have the right permissions, we shouldn't fallback to warning + temp directory, we should just use what is provided.
### What is your fix for the problem, implemented in this PR?
When home directory is not writable, but the required .gem and .bundle
are, we should use them instead of falling back to use tempdirs.
This creates a workaround for more restrictive setups using Omnibus
Docker or any hardened setup, to overcome the annoyances introduced by #4951.
### Why did you choose this fix out of the possible options?
This allows for distributions, package maintainers, etc to provide an alternative while keeping their hardenings requirements.
When provided the required folders with the required ownership/permission, we should not bother by not having any write permissions on the `$HOME` directory.
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
When home directory is not writable, but the required .bundle is,
we should use it instead of falling back to use tempdirs.
This creates a workaround for more restrictive setups using Omnibus
Docker or any hardened setup, to overcome the annoyances introduced by #4951.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
add option to Bundler#mkdir_p to force Bundler to not use sudo
### What was the end-user problem that led to this PR?
There is a bug for functionality that was added in #6258. In certain scenarios, Bundler will create a folder for a temporary gem install with `root:root` permissions. This is happening because [Bundler#mkdir_p](https://github.com/bundler/bundler/blob/master/lib/bundler.rb#L377) checks for `requires_sudo?` which is creating a folder owned by `root:root` when it should be creating the folder with the current user.
### What was your diagnosis of the problem?
See #6535
I can see that Bundler is creating the `bin` folder with `root:root` permissions
```
[vagrant@localhost ~]$ ls -la /tmp/bundler20180519-24861-1y67io7rake-12.3.1/
total 4
drwx------. 3 vagrant vagrant 17 May 19 07:36 .
drwxrwxrwt. 9 root root 4096 May 19 07:36 ..
drwxr-xr-x. 2 root root 6 May 19 07:36 bin
```
### What is your fix for the problem, implemented in this PR?
Add an option for `Bundler#mkdir_p` to prevent it from using `sudo` even though `requires_sudo?` is true.
Fixes #6535
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[bundle add] Add version prefix flexibility
### What was the end-user problem that led to this PR?
By default, on `bundle add` we use "pessimistic" way (~>) of versions. According to this [comment](https://github.com/bundler/bundler/issues/6553#issue-326023952) some users face problems.
### What was your diagnosis of the problem?
Adding flags to provide flexibility to change this declaration namely `optimistic` and `strict`
### What is your fix for the problem, implemented in this PR?
Adding flags to opt for other declarations.
### Why did you choose this fix out of the possible options?
Currently, its an experiment and I have added it to only `bundle add` but still the version locked in lockfile are "pessimistic". Need suggestions on this and on how to proceed.
Addresses #6553
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Enable bundler caching for generated travis config
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?
Whenever I create a gem using `bundle gem`, I always have to manually specify that I would like travis to cache bundler.
### What is your fix for the problem, implemented in this PR?
Specify `cache: bundler` in the generated .travis.yml.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | | |
Version 1.16.2
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix calling undefined `Gem::Util.inflate` in RubyGemsIntegration for old RubyGems versions
### What was the end-user problem that led to this PR?
RubyGems integration is calling `Gem::Util.inflate` which is not available in all supported versions of RubyGems.
### What was your diagnosis of the problem?
See https://travis-ci.org/bundler/bundler/jobs/368919903
### What is your fix for the problem, implemented in this PR?
Check if `Gem::Util` is defined, and if not, fallback to using the old way calling `inflate` in RubyGems
(cherry picked from commit 1eb812c8bdc4de6b052e2262b5d3d3d19f90d8a7)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix specs against RubyGems master
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 the specs on master are broken running against RubyGems master
### What was your diagnosis of the problem?
My diagnosis was This was broken by RubyGems changing how requirements are sorted.
### What is your fix for the problem, implemented in this PR?
My fix uses `Gem::Requirement` to get the same sorting rubygems has
### Why did you choose this fix out of the possible options?
I chose this fix because the sorting is different between rubygems versions
(cherry picked from commit 31b4b1e9ba2411b2543c14153416e1ecd2ddd15e)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix failing exec spec that is blocking 1.16.2
### Overview
There is a test that is [failing in travis](https://travis-ci.org/bundler/bundler/builds/365371973) which is preventing v1.16.2 from being released. The spec in question is checking the `BUNDLER_SPEC_SUB_VERSION` env var and changes the assertion of the test depending on the stubbed version. The issue is that the 1-16-stable branch does not really use `BUNDLER_SPEC_SUB_VERSION` and the spec is assuming it's testing Bundler 2.
### What is your fix for the problem, implemented in this PR?
Checking for `BUNDLER_SPEC_SUB_VERSION` is not really necessary in the first place because the test is already scoped for Bundler 1 & 2 (using rspec tags). This PR removes the checking for `BUNDLER_SPEC_SUB_VERSION`.
(cherry picked from commit b7684c7bf91c448b8ee6bf60d39353385a51e23b)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Document parameters and return value of Injector#inject
Summary: Use File.open instead of Kernel.open to avoid private method call when using Bundler::Injector in Ruby script.
### What was the end-user problem that led to this PR?
My app should allow users to install extensions at runtime. When using `Bundler::Injector`'s `inject` in a Ruby script, the internal method `append_to` fails with the error below.
Calling system('bundle inject GEM VERSION') is not feasible in my use case, since I want to inject the gem in a secondary Gemfile.
### What was your diagnosis of the problem?
The error that occurs when trying to inject a dependency through a call to `Bundler::Injector.inject`:
`bundler-1.16.1/lib/bundler/injector.rb:85:in 'append_to': private method `open' called for "Gemfile.local":String (NoMethodError)`
### What is your fix for the problem, implemented in this PR?
My fix replaces Kernel.open with File.open to open the Gemfile.
### Why did you choose this fix out of the possible options?
I chose this fix because it does not break current `bundle inject GEM VERSION` CLI behavior and does not introduce additional dependencies.
(cherry picked from commit 183c986dc89c25e332617fa3609efbed43f5df63)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=colby-swandale
Filter git uri credentials in source description
### What was the end-user problem that led to this PR?
The problem was HTTP basic auth credentials were leaking into Bundler's output when used in git sources
### What was your diagnosis of the problem?
My diagnosis was we needed to filter credentials in `Git#to_s`
### Why did you choose this fix out of the possible options?
I chose this fix because it doesn't require updating every place that uses `Source#to_s`, and is symmetric with what the rubygems source does to filter creds
(cherry picked from commit 822d5b278ecdae70912fe75517cf3cbdb1d53649)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Do not blow up when installing on a readonly filesystem without a hom…
…e directory
fixes https://github.com/bundler/bundler/issues/6461
```
docker run --read-only ruby ruby -r bundler/cli -e "puts Bundler::VERSION; Bundler::CLI.start(['exec', 'ruby', '-v'], :debug => true)"
/usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:193:in `rescue in tmp_home_path': `/root` is not writable. (Bundler::GenericSystemCallError)
Bundler also failed to create a temporary home directory at `/tmp/bundler/home':
There was an error accessing `/tmp/bundler/home`.
The underlying system error is Errno::EROFS: Read-only file system @ dir_s_mkdir - /tmp/bundler
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:181:in `tmp_home_path'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:172:in `user_home'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:197:in `user_bundle_path'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin.rb:99:in `global_root'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin/index.rb:73:in `global_index_file'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin/index.rb:32:in `initialize'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/plugin.rb:78:in `new'
```
@segiddins
(cherry picked from commit 6ce1eea14bc2d9917ea67d0103e0a7f15a0b62ec)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[Source::RubyGems] Allow installing when the path is `.`
### What was the end-user problem that led to this PR?
The problem was `bundle install` would fail when the path was configured to be the current working directory.
Fixes #6475.
### What was your diagnosis of the problem?
My diagnosis was `Gem::RemoteFetcher` caches `.gem` files differently when `Dir.pwd == download_dir`
### What is your fix for the problem, implemented in this PR?
My fix moves the file rubygems has downloaded to the cache directory we expect.
### Why did you choose this fix out of the possible options?
I chose this fix because it does not re-implement logic in rubygems, and it keeps the directory structure bundler generates consistent.
(cherry picked from commit ba49ed283fa20d313f95cdefcd32f8f82a786c9f)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix bundle lock when default gemfile is present
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 on running `bundle lock --lockfile=AlternativeGemfile.lock` if a default lockfile already exists then `AlternativeGemfile.lock` is not created.
### What was your diagnosis of the problem?
My diagnosis was that the [lock](https://github.com/bundler/bundler/blob/master/lib/bundler/definition.rb#L340) function does not check the file but for contents, so a new file is not created in case of an existing lockfile.
### What is your fix for the problem, implemented in this PR?
My fix was to check for the file existence.
Closes #6460
(cherry picked from commit cecdfdb5b2a76133b0a83093ff6d80d1ffd97b46)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bump the bundle_binstub check-length to 300 characters
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?
I could not start a binstub binary.
### What was your diagnosis of the problem?
Some packaging systems require modifications to the hash-bang
interpreter path, making them longer than normal. One such example of
this is the habitat-sh/habitat project. The result is that the 150
character limit does not find the regex it is looking for, and prevents
an otherwise valid binary from starting.
### What is your fix for the problem, implemented in this PR?
This change doubles the length of the check from 150 characters to 300
characters. This change has been validated in an impacted environment.
### Why did you choose this fix out of the possible options?
It was the most straightforward.
(cherry picked from commit fb38825ead6603588dae17b34b23f282548ee425)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Added license info to main README
Thought about doing this for a while but completely forgot about it. Added a link out to the MIT license from the bottom of the README. (Since it's considered a general best practice for info to be included in a README, and want to make sure the README is as complete as possible.)
(cherry picked from commit 257fb54da0003c3a67f6e7b3b5a242a4ba9c45cb)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Document the order Bundler loads settings
Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.
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...
...[confusion from end users](https://github.com/bundler/bundler/issues/6270) about the order that Bundler loads settings in.
Before:
```
This command allows you to interact with bundler's configuration system.
Bundler retrieves its configuration from the local application (`app/.bundle/config`),
environment variables, and the user's home directory (`~/.bundle/config`),
in that order of priority.
```
### What was your diagnosis of the problem?
My diagnosis was...
...[Colby pointed out how the bundle-config doc](https://github.com/bundler/bundler/issues/6334) needed to be updated to reflect this. After reviewing the `bundle-config` doc, it appears there was some information about how Bundler loads config settings, but it wasn't complete and as apparent to users. So I decided to separate the graph out and document the settings as a list so users could spot that easier.
### What is your fix for the problem, implemented in this PR?
My fix...
...was to verify the order of priority of settings and write them out as a list.
After:
```
This command allows you to interact with Bundler's configuration system.
Bundler loads configuration settings in this order:
1. Local config (`app/.bundle/config`)
2. Environmental variables (`ENV`)
3. Global config (`~/.bundle/config`)
4. Bundler default config
```
### Why did you choose this fix out of the possible options?
I chose this fix because...
it was clear that the document had to be updated, and lists are easier for readability.
fixes #6334
(cherry picked from commit 8b8b9634648e9c2c58c0a97ed583f174dbcad111)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Made small copy tweaks, removed redundant phrasing
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?
I did a cursory review of the `bundle help` doc to make sure the language still made sense. Everything still made sense, but I wanted to remove redundant phrases that could confuse users, and just tightened up punctuation.
### What is your fix for the problem, implemented in this PR?
My fix...
...was to make some small tweaks in capitalization, punctuation, and remove redundant phrasing that could confuse users.
### Why did you choose this fix out of the possible options?
I chose this fix because...
...simple to implement :)
(cherry picked from commit 3cad98f73b76baca15e34ea72bb32954b03f8b38)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[SpecGroup] Remove unused ivar
### What was the end-user problem that led to this PR?
The problem was this ivar was unused.
### What was your diagnosis of the problem?
My diagnosis was we should remove it. For performance, you know.
(cherry picked from commit 0fc3fc1c32bc633334df42aca3f7976c6444c24e)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
greysteil:handle-gem-specific-updates-non-local-platform, r=segiddins
Handle updating a specific gem for a non-local platform
Fixes https://github.com/bundler/bundler/issues/6350.
Kudos to @segiddins for the test.
(cherry picked from commit 91a3e3fd69bfb2fa5e5293dbe012c4ada0c7b49b)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Explain spec files and output a link to bundler.io guides
Resolves #6246
1. There is no helpful comment about `spec.files` method in a new gem's gemspec.
2. `$ bundle gem gem_name` is missing link to further reading about developing, testing and releasing the newly created gem.
1. Add a comment in the `newgem.gemspec.tt`
2. Add a message after new gem generation with link to [bundler.io guides](https://bundler.io/guides/creating_gem.html)
Example:
```bash
๛ ~/code/oss/tmp $ ../bundler/bin/bundle gem new_gem
Creating gem 'new_gem'...
create new_gem/Gemfile
create new_gem/lib/new_gem.rb
create new_gem/lib/new_gem/version.rb
create new_gem/new_gem.gemspec
create new_gem/Rakefile
create new_gem/README.md
create new_gem/bin/console
create new_gem/bin/setup
create new_gem/.gitignore
Initializing git repo in /Users/nesaulov/code/oss/tmp/new_gem
Gem 'new_gem' was successfully created. For detailed information on further steps please visit https://bundler.io/guides/creating_gem.html
๛ ~/code/oss/tmp $
```
(cherry picked from commit 94d328be35394eecce9b9d2b42848195e6f204c2)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
shime:check-if-stderr-is-closed-before-reporting-errors, r=segiddins
Fix to check if stderr was closed before writing to it
See https://github.com/bundler/bundler/issues/6190
The error is happening because we're not checking if stderr is closed prior to writing to it.
My fix is to add a check to determine if stderr was closed.
I chose to fix it here for a start and discuss with others if more checks were needed. Maybe we need to check if stderr is closed for all references of `$stderr.puts` and replace `abort` with `$stderr.puts` and `exit(1)`?
(cherry picked from commit 6a7af6b4016ad2c659a66cff86074f7dd52b3cdf)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix failure when exception backtrace is nil
Resolves #6342
### What was the end-user problem that led to this PR?
Instead of throwing a readable error, Bundler failed and generated an issue report template (see details in #6342).
### What was your diagnosis of the problem?
My diagnosis was that nil safety is hard in Ruby.
### What is your fix for the problem, implemented in this PR?
To check whether backtrace is nil before sending it a `take_while` method.
### Why did you choose this fix out of the possible options?
I chose this fix because I see no other solutions.
(cherry picked from commit 7f4c1a81b7b92e234fce0e3592d27c396d2451ac)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=colby-swandale
[CompactIndexClient::Updater] Use filesystem_access when copying files
### What was the end-user problem that led to this PR?
The problem was users could see the error template when they do not have write permissions to their temporary directory.
Closes https://github.com/bundler/bundler/issues/6289
### What was your diagnosis of the problem?
My diagnosis was we need to use `SharedHelpers.filesystem_access` when writing files.
### What is your fix for the problem, implemented in this PR?
My fix wraps usage of `cp`
(cherry picked from commit b7b847fe734dc8d95782d2e6510c8bc9a6631374)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bundler:segiddins/fail-gracefully-when-resetting-to-rev-fails, r=colby-swandale
[GitProxy] Fail gracefully when resetting to the given revision fails
### What was the end-user problem that led to this PR?
See https://github.com/bundler/bundler/issues/6324 for context.
The problem was when a git gem referenced a branch, and you tried to install on a machine without the revision in the lockfile cached, Bundler would print the following error:
```
Git error: command `git reset --hard cb70aded58b9215a495f0509e49daef930eec478` in directory
/home/deivid/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/bundler/gems/decidim-cb70aded58b9 has failed.
If this error persists you could try removing the cache directory
'/home/deivid/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/cache/bundler/git/decidim-9495d3039168996748af12c0fdb04debdea10392'
```
The problem was that removing the cache directory doesn't help.
### What was your diagnosis of the problem?
My diagnosis was we needed to print a `RevisionNotFound` error when that `git reset --hard` failed.
### What is your fix for the problem, implemented in this PR?
My fix rescues git command failures resulting from that `git reset --hard` and re-raises a more appropriate error message:
```
Revision cb70aded58b9215a495f0509e49daef930eec478 does not exist in the repository https://github.com/decidim/decidim. Maybe you misspelled it?
```
### Why did you choose this fix out of the possible options?
I chose this fix because it didn't involve bubbling information up from the git proxy to the definition. Ideally we'd re-rescue this error somewhere and suggest a `bundle update --source`, but that can be done in a separate PR.
(cherry picked from commit 21c262a36da1d1b4bfb71acf4de31edc94d796e8)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=segiddins
Use Bundler.rubygems.inflate instead of the Gem::Util method directly
### What was the end-user problem that led to this PR?
The problem was Bundler was using RubyGems methods directly that may change their interface over time.
### What was your diagnosis of the problem?
My diagnosis was we should use `Bundler.rubygems` to encapsulate those method calls.
(cherry picked from commit 331ade5e654b4cb5cfcafff159593d2bb63d5b1b)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix source_location call in PR 6237 and commit fbb1ff7
Thanks to @nobu for pointing out the error (which was mine). `source_location` returns an array, not a string.
(cherry picked from commit ffe58a33ecf36997d071b980e87239ccf5365421)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=indirect
Deprecate safe_level of `ERB.new` in Ruby 2.6
### What was the end-user problem that led to this PR?
The interface of `ERB.new` will change from Ruby 2.6.
> 2nd, 3rd and 4th arguments of ERB.new are deprecated. 2nd
> argument (safe_level) will be dropped in the future and
> some of those arguments (trim_mode, eoutvar) are changed to
> keyword arguments. [Feature #14256]
https://github.com/ruby/ruby/blob/v2_6_0_preview1/NEWS#stdlib-updates-outstanding-ones-only
The following addresses are related commits.
- ruby/ruby@cc777d0
- ruby/ruby@8b9a3ea
This change will cause the users to see a warning as described below.
### What was your diagnosis of the problem?
In Ruby 2.6, a warning is displayed when using the interface of Ruby 2.5 or lower.
This warning can also be confirmed in Travis CI.
```console
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
```
https://travis-ci.org/bundler/bundler/jobs/348560176#L1137-L1138
### What is your fix for the problem, implemented in this PR?
This PR suppresses the above deprecation warnings of ruby-head (Ruby 2.6) .
### Why did you choose this fix out of the possible options?
Switch `ERB.new` interface using `RUBY_VERSION`. Because Bundler supports multiple Ruby versions, it need to use the appropriate interface.
(cherry picked from commit 56a49bb2fe82c1887320b965338618fcc74a16e7)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improve yanked gem error message
The problem was that the error message for a yanked Gem told the user to:
> update your bundle to a different version of foo (1.0)
This is slightly misleading because in this example, foo 1.0 is the version that has been yanked. They should use any verion of foo **other** than 1.0.
My diagnosis was that the error message interpolated the gem specification (which converts to a string as "NAME (VERSION)") rather than just the name of the gem in this instance.
My fix was to change that occurrence of the gem specification to just the gem name.
I chose this fix because it was the only way that occurred to me to do it.
(cherry picked from commit 1f6469ffa4aa92e3ab0fe0eea74ee461fcbfee4a)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Document `# frozen_string_literal` in `bundle init` Gemfile
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?
An enhancement request to bundle-init docu as per - issue 6140
### What was your diagnosis of the problem?
n/a
### What is your fix for the problem, implemented in this PR?
Updated the man/bundle-init.ronn file to include brief description of frozen string literal, and added a SEE ALSO section with link to Gemfile(5) webpage
### Why did you choose this fix out of the possible options?
File edited to try and reflect the previous discussion regarding what was required.
(cherry picked from commit 5fb9e9a08512828ad93663787ac9cffbda5d599e)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use Gem::Util.inflate instead of Gem.inflate
### What was the end-user problem that led to this PR?
When I released RubyGems 3.0, users can not use bundler with it.
### What was your diagnosis of the problem?
bundler still uses deprecated methods with https://github.com/rubygems/rubygems/pull/2214
### What is your fix for the problem, implemented in this PR?
Replace `Gem.inflate` to `Gem::Util.inflate`
(cherry picked from commit ba63d2eab7d321091cbe3482521c8da021e10c70)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Remove comment with timestamp on `bundle add`
As discussed on #6193 this PR simply removes the comment timestamp when adding a gem via command line.
(cherry picked from commit 86e4b2a636fa2153bcd048dc084ace180cfe5c4a)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=indirect
Gracefully handle when the lockfile is missing spec entries for the current platform
### What was the end-user problem that led to this PR?
The problem was users could get `Unable to find a spec satisfying ... perhaps the lockfile is corrupted?` error messages, particularly when they use multiple platforms.
Fixes #6079.
### What was your diagnosis of the problem?
My diagnosis was the lockfile _was_ indeed corrupted, because it was missing `spec_name (version)` entries, but resolution could still be skipped (preventing those gems from being added back in).
### What is your fix for the problem, implemented in this PR?
My fix checks whether all specs are present _in the lockfile_ (e.g. not locally) for the current platform, and considers that a "change" that forces the resolver to run, allowing those missing specs to be added back to the bundle.
### Why did you choose this fix out of the possible options?
I chose this fix because it was a way to force re-resolution in a way that ties into our existing `#change_reason` infrastructure. Additionally, it shouldn't have much of a performance overhead, since the calculation is only made when we're converging locked specs anyways.
(cherry picked from commit 81854e0758b807a647ca9ce94bd6c2e325a62302)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Only trap INT signal and set to DEFAULT
### What was the end-user problem that led to this PR?
The problem was commands like `nohup bundler exec {program}` wouldn't work as intended. For example, if a `HUP` signal were to be sent to the process running the `bundle exec ..`, it should in theory not terminate. Because, `nohup` would `IGNORE` that signal. But, that is not what the case is case is currently.
### What was your diagnosis of the problem?
My diagnosis was, if a process/bundler execution already had a `SIGNAL` set to it, example `HUP`, then performing `bundle exec {program}`, would mean that bundler resets any prior `SIGNAL`s on that process and sets them to `DEFAULT`.
### What is your fix for the problem, implemented in this PR?
My fix to the problem is to only trap `SIGNAL`s that we think should be set to `DEFAULT`, in this case, `INT`.
### Why did you choose this fix out of the possible options?
I chose this fix because its lot less aggressive than setting every signal to `DEFAULT`, and gives us the work with a smaller set of `SIGNAL`s. It also felt cleaner than having to trap a signal first and then restore to its predecessor value.
----
This is a dump that shows the before and after signals, when `nohup bundle exec {program }` gets run.
```
SIGEXIT: Before Handler: (), Current Handler: (DEFAULT)
SIGHUP: Before Handler: (IGNORE), Current Handler: (DEFAULT)
SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT)
SIGQUIT: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGTRAP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGABRT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGIOT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGEMT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGSYS: Before Handler: (), Current Handler: (DEFAULT)
SIGPIPE: Before Handler: (), Current Handler: (DEFAULT)
SIGALRM: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGTERM: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGURG: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTSTP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCONT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCHLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTTIN: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTTOU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGIO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGXCPU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGXFSZ: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGPROF: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGWINCH: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGUSR1: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGUSR2: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGINFO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
```
From this, we can see only `INT` is being trapped by bundler
```
SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT)
```
hence, the only one being restored back to `DEFAULT`
----
Issue: https://github.com/bundler/bundler/issues/6150
(cherry picked from commit 5cf764d48b9c3a4299f39b6b1a7344665e2f3fd1)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix hang when gemspec has incompatible encoding
### What was the end-user problem that led to this PR?
The problem was that if a gemspec had a non ascii character on it, and the external encoding is not utf-8, bundler would fail with a very cryptic error. CircleCI is very likely to reproduce this bug since its base images default to `LANG=C`. See [here](https://circleci.com/gh/deivid-rodriguez/pry-byebug/12) for an example.
In bundler's master, `bundle install` seems to hang in this same situation. I have no idea why but CPU usage goes crazy (100%) when running something like `LANG=C bundle install` with such a gemspec.
Note that adding a utf-8 magic encoding comment seems to fix the problem, but I think `bundler` should just work in this situation, or at least give the user a more helpful error message. And of course never hang either.
### What was your diagnosis of the problem?
My diagnosis was that bundler was reading an incompatible character from the gemspec and was not able to deal with it, nor give a useful error message.
### What is your fix for the problem, implemented in this PR?
My fix initial fix was to at least give a better error message, preventing the method building the error message itself from blowing up due to incompatible encodings. This is the initial patch that I wrote to improve the error message:
```diff
diff --git a/lib/bundler/dsl.rb b/lib/bundler/dsl.rb
index 37bfe3674..79ef563d1 100644
--- a/lib/bundler/dsl.rb
+++ b/lib/bundler/dsl.rb
@@ -581,7 +581,14 @@ The :#{name} git source is deprecated, and will be removed in Bundler 2.0.
def parse_line_number_from_description
description = self.description
- if dsl_path && description =~ /((#{Regexp.quote File.expand_path(dsl_path)}|#{Regexp.quote dsl_path.to_s}):\d+)/
+ return [nil, description] unless dsl_path
+
+ quoted_expanded_dsl_path = Regexp.quote(File.expand_path(dsl_path))
+ quoted_dsl_path = Regexp.quote(dsl_path.to_s)
+
+ return [nil, description] unless Encoding.compatible?(quoted_dsl_path, description) && Encoding.compatible?(quoted_expanded_dsl_path, description)
+
+ if description =~ /((#{quoted_expanded_dsl_path}|#{quoted_dsl_path}):\d+)/
trace_line = Regexp.last_match[1]
description = description.sub(/#{Regexp.quote trace_line}:\s*/, "").sub("\n", " - ")
end
```
With that patch, the error would be more clear, pointing at the exact line in the gemspec where the incompatible character was found.
However, after that I considered that maybe bundler doesn't need to read the gemspec as a text file, but could read it "binarily". That seemed to fix the problem indeed and made the `bundle install` succeed in this situation.
### Why did you choose this fix out of the possible options?
I chose this fix because not only fixes the error message but also seems to make `bundler` just work.
(cherry picked from commit 83c23ecac258dfcec4ab3d552f0d09725bd09145)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Remove unnecessary executable bit from gem template.
This file is not executable at all, since the shebang line contains just placeholder for template expansion.
(cherry picked from commit ccc276ec0cd0591e73925746101f3b56ccc9333c)
|
