| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
(cherry picked from commit ece6829c46e4768aae13f970a54017c272bf974d)
|
| | |
|
| |
|
|
|
|
| |
Dynamically fetch expected rails version
This way, we don't have to update this expectation every time a new rails version comes out
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JuanitoFatas:fix/4914-gemfile-engine-symbol-and-string, r=segiddins
Support specify engine by symbol in Gemfile
This fixes #4914.
Our test suite did not run with jruby but I have manually verified this patch works. Details can be seen below.
<details>
<summary>View manual verification details</summary>
The spec I added in this PR works with jruby:
```
$ chruby jruby-9.1.2.0
$ ruby -v
jruby 9.1.2.0 (2.3.0) 2016-05-26 7357c8f Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [darwin-x86_64]
$ rspec spec/install/gemfile_spec.rb
Run options: exclude {:rubygems_master=>true, :git=>"=< 2.8.1", :rubygems=>"=< 2.6.4", :ruby=>"=< 2.3.0", :realworld=>true, :sudo=>true}
bundle install
with duplicated gems
will display a warning
with --gemfile
finds the gemfile
with gemfile set via config
uses the gemfile to install
uses the gemfile while in a subdirectory
with deprecated features
reports that lib is an invalid option
with engine specified in symbol <--------------------- HERE
should not report error <--------------------- HERE
Retried examples: 0
Finished in 43.89 seconds (files took 1.68 seconds to load)
6 examples, 0 failures
```
Real-world Gemfile also works after this patch:
```
$ ruby -v
jruby 9.1.2.0 (2.3.0) 2016-05-26 7357c8f Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [darwin-x86_64]
$ cat Gemfile
source "https://rubygems.org"
ruby '2.3.0', :engine => :jruby, engine_version: '9.1.2.0'
$ dbundle
The Gemfile specifies no dependencies
Bundle complete! 0 Gemfile dependencies, 1 gem now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
```
</details>
|
| |
|
|
|
|
|
|
|
|
| |
[RubygemsIntegration] Ensure redefined methods have the same visibility
Closes #4975
\c @indirect @headius
I'd love to get this out as 1.13.2 asap, if it works
|
| |
|
|
|
|
| |
[Definition] Avoid parsing lockfile twice on init
\c @chrismo
|
| |
|
|
|
|
|
|
| |
[EndpointSpecification] Raise a helpful error when parsing metadata fails
Would make diagnosing a recent issue around this easier
\c @indirect would love to get this into 1.13.1
|
| |
|
|
| |
::Rake::CommandFailedError doesn't exist.
|
| |
|
|
|
|
| |
Update bundle-exec docs for exec loading
See https://github.com/bundler/bundler/issues/4852 @indirect
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix message parenthesis color
Hello!
Using Bundler version 1.13.1 i noticed a small graphic inconsistency on parentheses color:
<img width="349" alt="screen shot 2016-09-19 at 16 16 10" src="https://cloud.githubusercontent.com/assets/557414/18635257/b41a0366-7e84-11e6-9664-174c90a0863f.png">
This commit resets the opening parenthesis color:
<img width="287" alt="screen shot 2016-09-19 at 16 27 08" src="https://cloud.githubusercontent.com/assets/557414/18635630/f7081b94-7e85-11e6-963c-8c2b869a9443.png">
Is this the expected behaviour? The spec was only checking the closing parenthesis color.
p.s:
Imho green parentheses look better here.
|
| |
|
|
|
|
|
|
| |
fixing NoMethodError on settings
When the Settings object is initialized with no root directory it cannot read the local_config. This used to not be a problem due to the fact that the `#load_config` method did not try to exit early. Since now it does it returns nil when the config is not present setting the @local_config instance variable to nil. The fix is to return an empty hash the same way the `#load_config` method would return if it encountered a problem later on.
The attached test proves that there is a problem and the fix makes the problem go away.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix GEM_PATH regression in 1.13.
_nth time is a charm ... here's the latest latest latest commit message_:
Fix disable_shared_gems bug & keep nested exec
tl;dr `--deployment` will copy _all_ gems to the `--path` now and a
proper fix is in place for nested bundle execs when `--path` is set and
RubyGems >=2.6.2 is being used.
Fixes #4974.
There's two problems blended in here. Let's trace the events here from
the beginning, shall we?
First off, from probably the first versions of Bundler, when
`disable_shared_gems` is true, the `GEM_PATH` gets internally overridden
and initialized to an empty string. This is done to make sure that later
in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path`
setting, otherwise it expands to include the system path.
In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases,
and that new code path calls `require "bundler/setup"`.
Later, issue #4592 was filed, showing that in cases like `--deployment`
where `disable_shared_gems` is true, Bundler couldn't find itself,
because Bundler never lives in the `--path` but only in system gems. And
as it would later be discovered, was not a problem with RubyGems 2.6.1,
but was a problem with >=2.6.2 (and older RubyGems it would seem, though
those weren't as thoroughly investigated).
We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code
initializing `GEM_PATH` to be initialized to `nil` instead of empty
string in all `disable_shared_gems` cases. But it created another bug,
filed as #4974, wherein system gems were no longer copied to the
`--path` when `disable_shared_gems` is true. In this commit here (#4992)
we've reverted the change so that `GEM_PATH` is now back to being
initialized to an empty string instead of `nil`.
That fixes #4974, but regresses #4592, and we needed a new way to fix
it.
After a few tortured attempts at this, I ran across issue #4602, a
similar report of nested bundle execs being broken, #4602 itself an
extension of #4381 reporting the same problem. It brought to light the
role the Rubygems version played in the problem.
When the `bundler` gem is installed and the wrapper is generated for any
gem executables, the contents of this wrapper are determined by the
Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper
calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of
`Gem.bin_path` with its own, and has for a long time made a special
exception for the Bundler gem itself, short-circuiting with the contents
of a special ENV variable called `BUNDLE_BIN_PATH`.
In Rubygems 2.6.2, `bin_path` was superseded by a new
`Gem.activate_bin_path` method which did what `bin_path` did but also
activated the gem. Bundler 1.13 added support for this, but it didn't
include the same short-circuit for bundler itself. (Alert user @taoza
even noticed this here
fcaab35#r56665282).
This commit also includes that short circuit for Rubygems >=2.6.2 now
and nested bundle exec should continue to work.
|
| |
|
|
|
|
|
|
|
|
| |
r=indirect
[LazySpecification] Select the best platform match when materializing
Closes #5006
This was not fun to track down >.<
|
| |
|
|
| |
[Settings] Make auto_install a bool key
|
| |
|
|
|
|
|
|
| |
Update specs to use compact_index 0.11
Also removed the penalty for adding requirements to dependencies!
\c @indirect
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Update vendored Molinillo to 0.5.1
See https://github.com/CocoaPods/Molinillo/releases/0.5.1
I'd love this to be a 1.13.1
(cherry picked from commit ffbb417d22592fe3b0a6e5f6008fc7eee491b027)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[RubygemsExt] Add missing require rubygems/source
The change referenced below as released in 1.13.0.rc.2, may attempt to reference Gem::Source without it being loaded, resulting in:
~~~
[!] There was an error parsing `Gemfile`:
[!] There was an error while loading `elided.gemspec`: uninitialized constant Gem::Source. Bundler cannot continue.
~~~
Observed this on ruby 2.2.5 with stock rubygems 2.4.5 as well as upgraded rubygems 2.6.6. Add this require.
f9de70ee931ca4a8500916fa9480f6df6c062626 by @segiddins:
> [RubygemsExt] return Source::Installed from #source when appropriate
(cherry picked from commit 3b5d04700aff686e0d119d4a7df329a19323f759)
|
| | |
|
| | |
|
| |
|
|
| |
see also #4901
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Block resolving to older versions during an update
This is currently behind the only_update_to_newer_versions setting
Closes https://github.com/bundler/bundler/issues/4511.
See https://github.com/bundler/bundler/issues/4856 and https://github.com/bundler/bundler/issues/4871
|
| |/
|
|
| |
This is currently behind the only_update_to_newer_versions setting
|
| |\
| |
| |
| |
| |
| | |
Add a setting for disable_exec_load
See #4852
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
include version numbers involved with warn_for_outdated_bundler_version
Can make it easier to understand what's going on.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Plugin] Life-cycle hooks
Implements life-cycle hook plugins.
This shows only [`before-install-all` hook](https://github.com/bundler/bundler/pull/4815/files#diff-0964e829e3db904ba7935ca3a933f111R22), but other hooks can be easily added in the similar fashion.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Filter out credentials in stderr message
This will close #4663
- [x] Fix broken tests
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Zehan Zhao <cnallenzhao@gmail.com>
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | | |
[Lock] Allow removing platforms
\c @indirect
|
