| Age | Commit message (Collapse) | Author |
|
lockfile
When dependencies in path sources have changed, we'll be re-resolving,
and we can't really know whether the resolution will be valid or invalid
for the Ruby platform, so skip the removal in that case.
https://github.com/rubygems/rubygems/commit/afc3b0956f
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
When a top level dependency is missing from the lockfile, and we're in
frozen mode, we should also print a "frozen error".
https://github.com/rubygems/rubygems/commit/3e82b835e3
|
|
This error message is also printed when using `bundler/setup` in frozen
model, so we're not necessarily installing any gems when it happens.
This new message play nicer with all situations.
https://github.com/rubygems/rubygems/commit/6874bbacce
|
|
I think it communicates better what's going on.
https://github.com/rubygems/rubygems/commit/07a25767a4
|
|
https://github.com/rubygems/rubygems/commit/ad52f840f2
|
|
https://github.com/rubygems/rubygems/commit/d91c245921
|
|
through ENV
The `deployment` setting sets `path` to `vendor/bundle` implicitly, but
that should only apply if `path` is not set explicitly, at any level.
https://github.com/rubygems/rubygems/commit/3552c064c1
|
|
These should all be passing on Bundler 3.
https://github.com/rubygems/rubygems/commit/4a8c172965
|
|
https://github.com/rubygems/rubygems/commit/e16aa47b8f
|
|
They are already tested above.
https://github.com/rubygems/rubygems/commit/23073dcece
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
If Gemfile has a lot of dependencies, we have an optimization that uses
the full index in that case, assuming it's going to be faster.
I think this is an old optimization that predates compact index API
times, I believe we no longer need it these days.
Also, since a few releases ago we check for circular dependencies when
resolving by looping through all versions of each name and removing
those that have circular dependencies that would trip up the resolver.
This loop becomes actually very slow when full indexes are used because
to find dependencies of a gemspec, we need to explicitly fetch the
marshaled gemspec (`gemspec.rz` endpoint) for it, so the optimization
has the opposite effect of making things very slow.
https://github.com/rubygems/rubygems/commit/2f46289bd3
|
|
When dependencies have changed, we'll be re-resolving, and we can't
really know whether the resolution will be valid or invalid for the Ruby
platform, so skip the removal in that case.
The fix worked, but made some other specs fail, and surfaced that the
`@dependencies_changed` attribute was actually being incorrect set when
explicitly unlocking. Fixed that with an early return.
https://github.com/rubygems/rubygems/commit/20d8f5e5d9
|
|
I've never seen this error in real life, and if it was happening, I
think it's either some server side issue that would need to be fixed or
some transient issue. We should move away from the full index, since
it's slow, so let's stop recommending it.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
https://github.com/rubygems/rubygems/commit/085d2776d8
|
|
locked
https://github.com/rubygems/rubygems/commit/24d2bf9cb2
|
|
https://github.com/rubygems/rubygems/commit/86b574824d
|
|
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
https://github.com/rubygems/rubygems/commit/27ed6870ce
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/cb4fc41cbc
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
* Replaces the wording of "is forbidden" with "cannot be used"
* Fixes the method signature of VersionRange::Empty#eql?
https://github.com/rubygems/rubygems/commit/8c6b3f130b
Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
We became a bit out of sync lately.
https://github.com/rubygems/rubygems/commit/6161a2610a
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
|
|
Given an existing application using native gems (e.g., nokogiri)
And a lockfile generated with a stable ruby version
When we test the application against ruby-head and `bundle install`
Then bundler should fall back to the generic ruby platform gem
Note that this test has been passing since 45931ac9
https://github.com/rubygems/rubygems/commit/0ecc6de378
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
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7020
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6987
|
|
from https://github.com/rubygems/rubygems/commit/bfb0ae69776069155d2092702bfbb5a12617d85a
Notes:
Merged: https://github.com/ruby/ruby/pull/6906
|
|
Pick from https://github.com/rubygems/rubygems/commit/823c776d951f3c35094611473ec77f94e8bf6610
Notes:
Merged: https://github.com/ruby/ruby/pull/6890
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6715
|
|
gems
https://github.com/rubygems/rubygems/commit/11229b16c3
|
|
|
|
https://github.com/rubygems/rubygems/commit/6214d00b2315ed37c76b1fbc1c72f61f92ba5a65
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
https://github.com/rubygems/rubygems/commit/06faad1e05
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6330
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/16c3535413afebcdbab7582c6017c27b5da8a8dc
Notes:
Merged: https://github.com/ruby/ruby/pull/6326
|
|
platforms
https://github.com/rubygems/rubygems/commit/f3c49ad3f7
|
|
Recently a changed was introduced to update the resolver platforms after
it has been created, in order to remove the "ruby" platform from it if
it's to be removed from the lockfile. However, it did not update the
`@resolving_only_for_ruby` instance variable in that case, so the
resolver was not properly doing the right thing anymore.
To fix this, I tweaked the code to restore not changing resolver
platforms after the resolver has been instantiated.
https://github.com/rubygems/rubygems/commit/8fbc30a1d0
|
|
Pick from https://github.com/rubygems/rubygems/commit/6b3a5a9ab0453463381a8164efb6298ea9eb776f
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
https://github.com/rubygems/rubygems/commit/0d321c9e3a
|
|
gems are unlocked
This is a regression from a change intended to raise errors when user
puts a gem under an incorrect source in the Gemfile by mistake. To fix
the issue, we revert the change that caused it and implement it in a
different way that restores the resolver independency from real
specifications. Now it deals only with names and versions and does not
try to materialize anything into real specifications before resolving.
https://github.com/rubygems/rubygems/commit/d2bf1b86eb
|
|
https://github.com/rubygems/rubygems/commit/69d0b4e10b
|
|
in frozen mode
https://github.com/rubygems/rubygems/commit/6e35a6edfe
|