| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
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. (Just considered a general best practice for info to be included in a README.)
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
| |
Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 :)
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Correctly re-install extensions when running `pristine` for a git source
### What was the end-user problem that led to this PR?
I have a gem with a native extension that is installed via git. I had to recompile it due to some needed build arguments.
### The problem was...
Running `bundle pristine` would not recompile it as expected.
### My diagnosis was...
After digging into the source, I discovered that the built extension lived in a different location than the cloned git repo. `bundle pristine` was only removing the git repo so the built extension was not getting rebuilt.
### My fix...
Update `bundle pristine` to also remove the built extension. For 2.0, this also required removing the built extension cache. Without doing that, the built extension directory would just be recreated from the cache.
### I chose this fix because...
As far as I know, it's the only solution.
Resolves #6294
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[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.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix some rescue calls that do not specifiy error type.
### What was the end-user problem that led to this PR?
The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues).
### What was your diagnosis of the problem?
My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack.
### What is your fix for the problem, implemented in this PR?
My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific.
### Why did you choose this fix out of the possible options?
No other ways of addressing this came to mind. I'd be happy to consider.
|
| | | |
| | |
| | |
| | | |
on Ruby 1.8.7
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Explain spec files and output a link to bundler.io guides
Resolves #6246
### What was the end-user problem that led to this PR?
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.
### What is your fix for the problem, implemented in this PR?
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 $
```
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
shime:check-if-stderr-is-closed-before-reporting-errors, r=segiddins
Fix to check if stderr was closed before writing to it
### What was the end-user problem that led to this PR?
See https://github.com/bundler/bundler/issues/6190
### What was your diagnosis of the problem?
The error is happening because we're not checking if stderr is closed prior to writing to it.
### What is your fix for the problem, implemented in this PR?
My fix is to add a check to determine if stderr was closed.
### Why did you choose this fix out of the possible options?
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)`?
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Update brew install for groff
[dupes](https://github.com/Homebrew/homebrew-dupes) tap is deprecated, `groff` is now in [hombrew-core](https://github.com/Homebrew/homebrew-core/blob/master/Formula/groff.rb).
Also fixed a missing single quote while I was at it :)
|
| |/ / / / |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix link to contributing doc
### What was the end-user problem that led to this PR?
Broken link to contributing doc in bot response
### What is your fix for the problem, implemented in this PR?
Corrected the link
Fixes #6332
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | | |
Add a POLICIES document
This isn't intended to be authoritative, but it's a start!
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | | |
The links to bundler.io were leading to a 404 error in GitHub because the full URL hadn't been written out.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Raise an error when attempting to set an expectation on nil
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 we could accidentally set an expectation on `nil`, leading to an RSpec warning
### What was your diagnosis of the problem?
My diagnosis was we should just error when we do so
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add a spec for bundle lock not downloading gems
### What was the end-user problem that led to this PR?
The problem was we were unsure (in https://github.com/bundler/bundler/issues/6312) whether lock had this behavior.
### What was your diagnosis of the problem?
My diagnosis was it did, and I came to that conclusion via this test!
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
