| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
installed
https://github.com/rubygems/rubygems/commit/a087c452ad
|
|
When converging locked specifications to select the ones that should be
preserved while resolving, we can avoid having to do a second pass to
ignore the ones that have been explicitly unlocked.
https://github.com/rubygems/rubygems/commit/411742703e
|
|
As long as some spec in the materialization is complete.
https://github.com/rubygems/rubygems/commit/9a673b0bbb
|
|
https://github.com/rubygems/rubygems/commit/3041b3d784
|
|
This gives more flexibility to allow further improvements.
https://github.com/rubygems/rubygems/commit/f11a890f5e
|
|
most_specific_locked_platform
So there's no need to pass it around in so many places.
https://github.com/rubygems/rubygems/commit/784ab7481b
|
|
https://github.com/rubygems/rubygems/commit/0c3a65871a
|
|
https://github.com/rubygems/rubygems/commit/d8d68cc00e
|
|
to be conservative
When converging specification to pass the set of versions that should be
preserved from the lockfile during resolution, we should make sure all
top level gems are considered, and only exclude those gems themselves
(and not their dependencies) if their locked versions happen to not be
satisfied by an edited Gemfile.
https://github.com/rubygems/rubygems/commit/ed2f1b7b88
|
|
https://github.com/rubygems/rubygems/commit/d0f789970f
|
|
sometimes
When used with `LazySpecification` objects, `SpecSet#for` was
incorrectly considering development dependencies. This did not cause any
issues because all usages of this method with `LazySpecification`'s are
not strict, meaning the pass `check = false` and ignore incomplete
specifications. But it was still doing more work than necessary because
development dependencies were still added to the `deps` array for
processing and then ignored because of not being found in the spec set.
Same when converging path specifications and replacing their dependencies.
https://github.com/rubygems/rubygems/commit/6afca8a95f
|
|
https://github.com/rubygems/rubygems/commit/df2c9eb52f
|
|
https://github.com/rubygems/rubygems/commit/c382b606bd
|
|
Due to a typo in the spec, the issue was not caught initially. If
Bundler does not need to re-resolve, `bundle lock` is a noop so Bundler
does not add checksums.
To fix the issue, we do something similar to what `bundle install` does,
just without actually installation. First set the domain (local or
remote) according to whether a re-resolve is necessary, and then
materialize lazy specifications into real specifications, so that
checksums are actually fetched from each source.
https://github.com/rubygems/rubygems/commit/84b6f4ee96
|
|
I always found the `resolve_if_necessary` method pretty confusing
because by reading it, it suggests that resolution always happens, and
the point is whether that needs to be local or remote. This commit tries
to make that more clear.
https://github.com/rubygems/rubygems/commit/93d6861ee8
|
|
All we need is to setup remote or local sources appropriately.
https://github.com/rubygems/rubygems/commit/3ceff46a2a
|
|
In particular, when a gem registry transitive dependency is changed to a
git source direct dependency.
https://github.com/rubygems/rubygems/commit/bcdc7660d9
|
|
https://github.com/rubygems/rubygems/commit/9964c16bb9
|
|
https://github.com/rubygems/rubygems/commit/c5a9449069
|
|
https://github.com/rubygems/rubygems/commit/508fb45b76
|
|
https://github.com/rubygems/rubygems/commit/2a36af0f38
|
|
There seems to be no reason why the install should be serial for --local.
The packages are still installed in the right dependency order in this case, so that parallel install can be used.
This patch disables parallel install only in case of no_install_needed.
Also remove the `option` argument, which is effectifely not used.
https://github.com/rubygems/rubygems/commit/5da934ddb6
|
|
checksums in fresh lockfiles
https://github.com/rubygems/rubygems/commit/50b9ef8589
|
|
https://github.com/rubygems/rubygems/commit/bc2537de71
|
|
https://github.com/rubygems/rubygems/commit/43c0c41c6b
|
|
existing lockfile
https://github.com/rubygems/rubygems/commit/0a9c1ce60d
|
|
After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.
That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.
So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.
Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?
The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.
So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.
https://github.com/rubygems/rubygems/commit/17499cb83f
|
|
dependencies
https://github.com/rubygems/rubygems/commit/5e933968a2
|
|
https://github.com/rubygems/rubygems/commit/92196ccfdb
|
|
|
|
wrong source
https://github.com/rubygems/rubygems/commit/1e5780db0a
Co-authored-by: Taylor Thurlow <thurlow@hey.com>
|
|
https://github.com/rubygems/rubygems/commit/d5dce93167
|
|
https://github.com/rubygems/rubygems/commit/432fe083a6
|
|
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
https://github.com/rubygems/rubygems/commit/06eec6d855
|
|
3.0 has been EOL since march, drop support for it before the 3.4 release is cut
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
https://github.com/rubygems/rubygems/commit/fc1f03b06a
|
|
This was introduced by https://github.com/rubygems/rubygems/commit/0b7be7bb7705, because
the original patch was not adapted to some recent refactorings.
https://github.com/rubygems/rubygems/commit/0bca60d6e5
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
|
https://github.com/rubygems/rubygems/commit/03ddfd7610
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
|
|
https://github.com/rubygems/rubygems/commit/0b7be7bb77
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
|
|
The original implementation of this flag was too naive and all it did
was restricting gems to locally installed versions if there are any
local versions installed.
However, it should be much smarter. For example:
* It should fallback to remote versions if locally installed version
don't satisfy the requirements.
* It should pick locally installed versions even for subdependencies not
yet discovered.
This commit fixes both issues by using a smarter approach similar to how
we resolve prereleases:
* First resolve optimistically using only locally installed gems.
* If any conflicts are found, scan those conflicts, allow remote
versions for the specific gems that run into conflicts, and
re-resolve.
https://github.com/rubygems/rubygems/commit/607a3bf479
Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>
|
|
update <specific_gem>` is run
https://github.com/rubygems/rubygems/commit/eec6830c04
|
|
https://github.com/rubygems/rubygems/commit/651cf3ea7a
|
|
When resolving on truffleruby, and multiple platforms are included in
the lockfile, Bundler will not respect existing platforms, but always
force ruby variants. That means removal of existing version specific
variants, introducing lockfile churn between implementations.
To prevent this, we introduce the distinction between
`Dependency#force_ruby_platform`, only settable via Gemfile, and
`Dependency#default_force_ruby_platform`, which is always true on
truffleruby for certain dependency names. This way, when resolving
lockfile gems for other platforms on truffleruby, we keep platform
specific variants in the lockfile.
However, that introduces the problem that if only platform specific
variants are locked in the lockfile, Bundler won't be able to
materialize on truffleruby because the generic variant will be missing.
To fix this additional problem, we make sure the generic "ruby" platform
is always added when resolving on truffleruby.
|
|
include the current platform
https://github.com/rubygems/rubygems/commit/afb7a6d754
|
