| Age | Commit message (Collapse) | Author |
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8126
|
|
https://github.com/rubygems/rubygems/commit/e8a4184429
|
|
https://github.com/rubygems/rubygems/commit/e30e86aa60
|
|
https://github.com/rubygems/rubygems/commit/9583a7eb82
|
|
https://github.com/rubygems/rubygems/commit/d0c1d97105
|
|
https://github.com/rubygems/rubygems/commit/d61c1362e7
|
|
https://github.com/rubygems/rubygems/commit/78807add23
|
|
https://github.com/rubygems/rubygems/commit/456fd05d3a
|
|
Bundler is special since it's not actually locked in the lockfile as a
regular gem (only via `BUNDLED WITH`). So exclude it from that check.
https://github.com/rubygems/rubygems/commit/9f1756ec47
|
|
https://github.com/rubygems/rubygems/commit/258476c38a
|
|
https://github.com/rubygems/rubygems/commit/46cd9be69a
|
|
https://github.com/rubygems/rubygems/commit/57cfe7cf8d
|
|
https://github.com/rubygems/rubygems/commit/c431a1df52
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
If we're in inline mode, Bundler first resolves using only local gems,
and if some gems are missing, then it re-resolves using remote gems.
However, "source resolution" from the initial "local" try was being
memoized, resulting in Bundler not looking for some gems remotely in the
second resolution.
This commit forces a proper re-resolve in this case.
https://github.com/rubygems/rubygems/commit/fdc631075e
|
|
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
Nicer :)
https://github.com/rubygems/rubygems/commit/c0ab2893c3
|
|
https://github.com/rubygems/rubygems/commit/3139587be9
|
|
to #windows?. (This is done instead of logging a deprecation warning.)
https://github.com/rubygems/rubygems/commit/b9fcc7c0ab
|
|
Pick from https://github.com/rubygems/rubygems/commit/e9304aed7e43308b99e70c2f7b92028315fee8a5
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
inline gemfile
https://github.com/rubygems/rubygems/commit/fa6e6ea95c
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
from https://github.com/rubygems/rubygems/commit/0635c1423db5d7c461d53bf0c3329bca75de7609
Notes:
Merged: https://github.com/ruby/ruby/pull/7094
|
|
from https://github.com/rubygems/rubygems/commit/bfb0ae69776069155d2092702bfbb5a12617d85a
Notes:
Merged: https://github.com/ruby/ruby/pull/6906
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
https://github.com/rubygems/rubygems/commit/c5b2960388
|
|
https://github.com/rubygems/rubygems/commit/f9a51e4380
|
|
RubyInstaller has released patch versions backporting their changes to
not load `fiddle` on boot, so all these are no longer necessary.
https://github.com/rubygems/rubygems/commit/05a307deb2
|
|
After recent musl support was added, Bundler started hanging in musl
platforms. I identified the issue where valid candidates were being
filtered out because their platform was specified as a string, and thus
`Gem::Platform.match_spec?` which under the hood ends up calling
`Gem::Platform#===` would return `nil`, because it does not support
comparing platforms to strings.
In particular, `Bundler::EndpointSpecification`'s platform coming from
the API was not instantiated as a `Gem::Platform`, hence the issue.
Also, this spec surfaced another issue where a bug corrected in
`Gem::Platform#match_platforms` had not been yet backported to Bundler.
So this commit also backports that to get the spec green across RubyGems
versions.
Finally, the fix in `Bundler::EndpointSpecification` made a realworld
spec start failing. This spec was faking out `rails-4.2.7.1` requirement
on Bundler in the `Gemfile.lock` file to be `>= 1.17, < 3` when the real
requirement is `>= 1.17, < 2`. Due to the bug in
`Bundler::EndpointSpecification`, the real requirement provided by the
compact index API (recorded with VCR) was being ignored, and the
`Gemfile.lock` fake requirement was being used, which made the spec
pass. This is all expected, and to fix the issue I changed the spec to
be really realworld and don't fake any Bundler requirements.
https://github.com/rubygems/rubygems/commit/faf4ef46bc
|
|
platforms
https://github.com/rubygems/rubygems/commit/f3c49ad3f7
|
|
skips install
If the application has the `no_install` setting set for `bundle
package`, then `bundler/inline` would silently skip installing any gems.
https://github.com/rubygems/rubygems/commit/7864f49b27
|
|
Pick from https://github.com/rubygems/rubygems/commit/8331e63263081a6aa690d8025d2957f30c4e814a
Notes:
Merged: https://github.com/ruby/ruby/pull/6209
|
|
https://github.com/rubygems/rubygems/commit/482077d185
|
|
Merge from https://github.com/rubygems/rubygems/commit/2af2520b4a7ab1c6eb1fdc3d2ef4d8c062d96ad7
Notes:
Merged: https://github.com/ruby/ruby/pull/6184
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6124
|
|
When testing under the ruby/ruby setup, mkmf.rb needs to the `$extout`
global variable set properly.
This is because, in this particular case, the `ruby.h` header needed to
compile extensions is constructed from
`$(extout)/include($arch)/ruby/config.h` but `$extout` is not set by
default.
I tried to fix this in mkmf.rb itself but I couldn't figure it. But
setting it externally to workaround the issue fixes the specs, so I'll
start with that. Also setting it externally causes issues when running
specs upstream against Ruby 2.3 (I guess because of some difference with
Ruby 2.3 mkmf.rb implementation). So I'm avoiding doing it on Ruby 2.3 to
woraround that.
https://github.com/rubygems/rubygems/commit/d782984585
|
|
https://github.com/rubygems/rubygems/commit/70ff7cee9f
|
|
https://github.com/rubygems/rubygems/commit/8e68c57457
|
|
https://github.com/rubygems/rubygems/commit/125415593ead9ab69a9f0bb5392c9d7ec61b1f51
|
|
https://github.com/rubygems/rubygems/commit/1fd818743e
|
|
install output
The lockfile is completely ignored in inline mode, yet the previous
output would suggest it wasn't.
https://github.com/rubygems/rubygems/commit/763125a745
|
|
https://github.com/rubygems/rubygems/commit/531d6b5fee
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5512
|
|
the current specific platform
https://github.com/rubygems/rubygems/commit/9ca371adf8
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5350
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5342
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5325
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5317
|
|
`$LOAD_PATH`
This way, if some default gem has been required before bundler, and
rubygems has enhanced the `$LOAD_PATH` to use the latest version in the
system, further requires of that default gem after bundler has been
activated will use the same version and don't cause redefinition
warnings or worse problems derived from the fact of mixing up two
different versions. That, unless the gem is a `Gemfile` dependency. In
that case, we'll get a mismatch error anyways as we do now.
This fix doesn't mean that all default gems internally used by
bundler/rubygems are now supported inside `Gemfile`'s. That should be
handled case by case, but it will now bite people only when they try to
add the gem to their `Gemfile`, not before.
https://github.com/rubygems/rubygems/commit/7325530547
|
|
It doesn't add anything.
https://github.com/rubygems/rubygems/commit/ece3c864df
|