| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| | |
Version 1.11.0.pre.1
|
| |/ |
|
| |\
| |
| | |
Documents lock command's `--update` option
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Explain why we don't use HTTPS for github sources
There are frequent pull requests proposing this change, which has already been merged to 2-0-dev.
Hopefully, this will help avoid so much wasted time.
|
| |/
|
|
|
| |
There are frequent pull requests proposing this change, which has
already been merged to 2-0-dev.
|
| |\
| |
| |
| | |
More rubocop_todo cleanup
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Restrict platforms when using gemspec in DSL
When referencing a `gemspec` in the `Gemfile`, restrict what platforms to check against to just those defined by the `gemspec` itself.
This fixes #4102
|
| | | |
| | |
| | |
| | |
| | |
| | | |
gemspec
This fixes #4102
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[Lock] Add support for specify gems to `bundle lock` command
This Pull Request adds the ability to specify gems in bundle lock command via command-line option,
so that this is allowed:
```
bundle lock --gems devise
```
or
```
bundle lock --gems devise ominiauth
```
In this way, we can use lock command for specific gems without downloading any gem.
Thanks!
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit adds the ability to specify gems in `bundle lock` command via `--update` option.
After this commit, if no list is given:
```
bundle lock --update
```
will update all gems.
Or update a list of specified gems:
```
bundle lock --update devise ominiauth
```
In this way, we can use lock command for specific gems without downloading any gem.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Retry `Fetcher#specs` with `Bundler::Retry`
As mentioned in https://github.com/heroku/heroku-buildpack-ruby/pull/435, bundler failed at the step of fetching version metadata:
```
Fetching version metadata from https://rubygems.org/Net::HTTPInternalServerError: <?xml version=\"1.0\" encoding=\"UTF-8\"?>
<Error><Code>InternalError</Code><Message>We encountered an internal error.
Please try
again.</Message><RequestId>E7402EA19C5D6803</RequestId><HostId>hzuvaA1JAZX6ST+OL4ARYeAqZ/tgkM2yOjZgBq6Panu10YzWtfNNozOg8N5qR3gxFE/sUfYGP48=</HostId></Error>
```
It turns out the retry logic doesn’t cover fetching source index, gem metadata, version metadata and dependency metadata. A new method `Fetcher#specs_with_retry` is added to wrap `Fetcher#specs` with `Bundler::Retry` which reties when bundler fails in the mentioned cases.
/cc @schneems
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As mentioned in https://github.com/heroku/heroku-buildpack-ruby/pull/435, bundler failed at the step of fetching version metadata:
```
Fetching version metadata from https://rubygems.org/Net::HTTPInternalServerError: <?xml version=\"1.0\" encoding=\"UTF-8\"?>
<Error><Code>InternalError</Code><Message>We encountered an internal error.
Please try
again.</Message><RequestId>E7402EA19C5D6803</RequestId><HostId>hzuvaA1JAZX6ST+OL4ARYeAqZ/tgkM2yOjZgBq6Panu10YzWtfNNozOg8N5qR3gxFE/sUfYGP48=</HostId></Error>
```
It turns out the retry logic doesn’t cover fetching source index, gem metadata, version metadata and dependency metadata. A new method `Fetcher#specs_with_retry` is added to wrap `Fetcher#specs` with `Bundler::Retry` which reties when bundler fails in the mentioned cases.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use exe instead of bin for BUNDLE_BIN_PATH fallback
Looks like these got moved.
I'm having a hard time getting this to actually fail in the tests. Here's a gist of something that fails:
Gemfile
----------
```ruby
source 'https://rubygems.org'
gem 'rake'
```
Rakefile
-----------
```ruby
desc "foo"
task :foo do
sh 'bundle -v'
end
```
> bundle install
> bundle install --deployment
> bundle exec rake foo
```
bundle -v
/Users/jmundrawala/.rbenv/versions/2.1.2/bin/bundle:23:in `load': cannot load such file -- /Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/bundler-1.10.6/bin/bundle (LoadError)
from /Users/jmundrawala/.rbenv/versions/2.1.2/bin/bundle:23:in `<main>'
rake aborted!
Command failed with status (1): [bundle -v...]
/Users/jmundrawala/workspace/bundler/foo/Rakefile:4:in `block in <top (required)>'
Tasks: TOP => foo
(See full trace by running task with --trace)
```
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Updates Contributor Covenant to 1.3.0
The code of conduct template also now inserts email address for contact purposes.
|
| | | |_|_|/
| |/| | |
| | | | | |
The code of conduct template also now inserts email address for contact purposes.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | | |
Fix edgecases spec for new gxapi_rails version
\c @indirect
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Check silence_root_warning option to skip warning on root install cmds
Adds a new setting `silence_root_warning` (environment variable: `BUNDLE_SILENCE_ROOT_WARNING`) that skips the default warning when `install` is run as root.
The warning is useful but I think it should be able to be disabled if the user knows what he's doing, it's handy when run inside Docker containers (which by default run as root), or other environments where root is used.
Also adds a new `preserve_env` option to `bundle` helper in tests which allows running commands under sudo with the `-E` flag (preserve environment) as opposed to the default env_reset. Without this, the command would be run without our flag which makes it impossible to test. There might be cleaner ways to achieve this, though.
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
r=segiddins
Fix bundle console IRB fallback
The fallback to IRB for `bundle console` is currently broken, due to a missing `require 'irb'`:
```bash
bundle config console pry
bundle console
Couldn't load console pry
Could not find constant IRB
```
This fixes the fallback and also alters the error message to indicate the fallback to irb.
While investigating the fix I noticed that the `bundle console` specs were broken and only worked because the expected strings were both contained in the error message.
In order to test an alternate console and the fallback behavior, I added a fake pry gem that implements the minimum required api. I also replaced `__callee__` with `__method__` for ruby 1.8.7 compatibility.
|
| | | | | | | |
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The previous specs only worked by accident, because the error message
"Couldn't load pry\nCould not find constant IRB\n" contained both of
the strings expected by the assertions.
In order to test loading an alternate console without adding a permanent
dependency, we can use a fake pry gem that implements the minimum
required api.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
[RuboCop] Update to 0.35.1
|
| |/ / / / / |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Extracting a new "GemInstaller" from installer.rb
My goal was to reveal the main part of install_gem_from_spec. From my
perspective the main part is:
1. Install
2. Generate stubs
3. Print message to the user
(4. handle exceptions)
While working on it I found that Bundler::Installer's run method and
instance variables weren't used when installing gems with
install_gem_from_spec. The installer was (and still is) only used to
generate executable stubs.
So I inserted the new GemInstaller in ParallelInstaller; passing the
instantiated Bundler::Installer to the GemInstaller only to generate
the executable stubs.
Based on this I would continue by extracting two BinstubGenerator
classes and removing GemInstaller's dependency on Bundler::Installer,
possibly allowing for a more concise way to generate binstubs in other
parts of bundler.
I was a bit intimidated by the amount of installers and weary to add
another one to this contested namespace. So I checked in with
@indirect who approved of the general direction of the refactoring and
suggested to rename the old GemInstaller to RubyGemsGemInstaller.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
perspective the main part is:
1. Install
2. Generate stubs
3. Print message to the user
(4. handle exceptions)
While working on it I found that Bundler::Installer's run method and
instance variables weren't used when installing gems with
install_gem_from_spec. The installer was (and still is) only used to
generate executable stubs.
So I inserted the new GemInstaller in ParallelInstaller; passing the
instantiated Bundler::Installer to the GemInstaller only to generate
the executable stubs.
Based on this I would continue by extracting two BinstubGenerator
classes and removing GemInstaller's dependency on Bundler::Installer,
possibly allowing for a more concise way to generate binstubs in other
parts of bundler.
I was a bit intimidated by the amount of installers and weary to add
another one to this contested namespace. So I checked in with
@indirect who approved of the general direction of the refactoring and
suggested to rename the old GemInstaller to RubyGemsGemInstaller.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Add a basic bundle lock manual [ci skip]
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
Clarify the documentation for --jobs
|
