| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
https://github.com/rubygems/rubygems/commit/d9a003b4e7
|
|
|
|
https://github.com/rubygems/rubygems/commit/5351e01b32
|
|
https://github.com/rubygems/rubygems/commit/d842e2092f
|
|
https://github.com/rubygems/rubygems/commit/e7d31405ea
|
|
https://github.com/rubygems/rubygems/commit/b211eeacba
|
|
https://github.com/rubygems/rubygems/commit/8771fbf53d
|
|
underscore
https://github.com/rubygems/rubygems/commit/a4bfa2ef94
|
|
https://github.com/rubygems/rubygems/commit/9a3ed682a0
|
|
https://github.com/rubygems/rubygems/commit/348c82311f
|
|
https://github.com/rubygems/rubygems/commit/c98677d073
|
|
https://github.com/rubygems/rubygems/commit/63efdac045
|
|
https://github.com/rubygems/rubygems/commit/1ff3e7450a
|
|
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
|
|
Revert "[ruby/syntax_suggest] Remove unnecessary `--color` option"
This reverts commit 588dd44d418d56dce3f2a388c4021d11f9aa4324.
|
|
It is enabled automatically if possible. Forcing this option makes
https://github.com/rspec/rspec-core/pull/3017 useless.
https://github.com/ruby/syntax_suggest/commit/8e7141b472
|
|
While working on locking multiple platforms by default, I got an
infinite resolution loop in one of our resolver specs.
The culprit ended up being that when dealing with lockfile specs with
incomplete dependencies (spec appears in lockfile, but its dependencies
don't), those specs were not being properly expired and that tripped up
resolution.
The issue for some reason only manifests when dealing with multiple
lockfile platforms, that's why it only manifested when working on
locking multiple platforms by default.
https://github.com/rubygems/rubygems/commit/4ca72913bb
|
|
This reverts commit 69580f8b72f41c58cae57d1ada4db909922b3891.
|
|
This reverts commit https://github.com/rubygems/rubygems/commit/a20585b4512d.
https://github.com/rubygems/rubygems/commit/aa9102659e
|
|
https://github.com/rubygems/rubygems/pull/6541
https://github.com/rubygems/rubygems/commit/21e07a04a1
|
|
|
|
to Bundler.
https://github.com/rubygems/rubygems/commit/d768be0c65
|
|
Plugins don't use a lockfile, so ignore frozen related settings.
https://github.com/rubygems/rubygems/commit/f17a3bb81f
|
|
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
|
|
unlocking
Bundler is very conservative by default, trying to preserve versions
from the lockfile as possible, and never downgrading them. However, when
it runs into a resolution error, it still tries to find a valid
resolution.
This fallback behavior was too "brute-force" though, completely
unrestricting any gem found in the resolution conflict, and that could
lead to direct dependencies being downgraded in some edge cases.
Instead, unlock things a bit more carefully:
* First try unlocking fully pinned indirect dependencies, but leave a
lower bound requirement in place to prevent downgrades.
* Then try unlocking any fully pinned dependency, also leaving a lower
bound requirement in place.
* Finally completely unrestrict dependencies if nothing else worked.
https://github.com/rubygems/rubygems/commit/7f55ed8302
|
|
https://github.com/rubygems/rubygems/commit/3561ac23d6
|
|
Prereleases are NOT considered even when the dependency specification
includes a prerelease segment, if the dependency is not locked. To me
that doesn't make sense, because I could create a Gemfile with say gem
"rails", ">= 7.0.0.beta1" and I'd expect prereleases considered there
even if there's no lock file yet.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
https://github.com/rubygems/rubygems/commit/61ec0c8389
|
|
I recently ran into very nasty issues with dynamic symbols clashing between
two native gems.
I believe the overwhelming majority of native gems don't want to export
their symbols, so hidding them by default would make sense to me.
https://github.com/rubygems/rubygems/commit/449624aa54
|
|
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
|
|
We're actually already using the full index here, so it makes no sense
to suggest retrying the same thing.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
The debug message suggests retrying using `--full-index`, but the retry
is happening automatically. Just log that we are falling back to the
full index, like we do with other errors.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Sometimes we'll have an heterogenous array of specs which include
`Gem::Specification` objects, which don't define `#identifier`. Let's
use `#full_name` consistently.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Recent bugs fixed made me realize we were relying on state too much
here. We only need to keep incomplete specs to be able to expire them
and retry resolution without them locked. If we use a separate class, we
can do that more transparently and handle them just like we handle
"missing specs".
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
https://github.com/rubygems/rubygems/commit/05cc97bdf8
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
https://github.com/rubygems/rubygems/commit/085d2776d8
|
|
`bin/console` file
This is just a suggestion, but since recent versions of Ruby have shipped with a `binding.irb` that provides almost all of the features that `pry` pioneered, it may be time to remove this suggestion in the name of simplicity and not confusing newer developers who aren't familiar with what to use.
|
|
unrelated git sources directly
Since Bundler 2.4, we will try to checkout any branch specified in the
Gemfile, while until Bundler 2.3 we would directly checkout the locked
revision.
This should not make any difference in most situations, but in some edge
cases, like if the branch specified in the `Gemfile` has been renamed,
but the locked revision still exist, it causes an error now while before
it would update the lockfile without issues.
I debated which behavior was best, since I was not sure. But my
conclusion is that if the situation does not require expiring the
lockfile source in favor of the Gemfile source, we should use the locked
revision directly and proceed happily. So I restored Bundler 2.3
behavior.
I think this is consistent with how yanked gems are handled, for example.
Of course, if explicitly updating the git source itself, or all gems, we
will still get any errors like missing branches related to the git source.
|
|
This was working fine for direct dependencies using
`force_ruby_platform` explicitly through Gemfile, but not for indirect
dependencies. In general, indirect dependencies do not have this
property set, but in truffleruby this is different and the default value
is to have it set.
|
|
This should be a very rare edge case, however, it does happen when using
a .dev version of Bundler because in that case, that's the only version
that the resolver considers, and it should not be ignored.
We could've special cased this specifically for Bundler, but I think it
does make sense for every gem.
|
|
Just like gem sources, a "style-only" change, like adding a trailing
slash, should not expire them.
|
|
https://github.com/rubygems/rubygems/commit/16f381be4b
|
|
locked
https://github.com/rubygems/rubygems/commit/24d2bf9cb2
|
|
https://github.com/rubygems/rubygems/commit/3139587be9
|
