| Age | Commit message (Collapse) | Author |
|
https://github.com/rubygems/rubygems/commit/85371a961a
|
|
remote resolution
https://github.com/rubygems/rubygems/commit/50dd93e217
|
|
were not used
https://github.com/rubygems/rubygems/commit/5ce9a7ff17
|
|
cache
Even if all gems are properly installed and no resolve is needed, we
recently started always reading all packages in `vendor/cache` and
extracting specifications from them.
This commit fixes the problem by longer making considering cached specs
the default and only enable them when a resolve is actually needed.
https://github.com/rubygems/rubygems/commit/edeb2c42bf
|
|
It's a sources specific concern, so keep it there. It allows to simplify
the code quite a lot.
https://github.com/rubygems/rubygems/commit/639f0b72f4
|
|
lockfile
https://github.com/rubygems/rubygems/commit/4e048bc255
|
|
https://github.com/rubygems/rubygems/commit/5074c58ffb
|
|
https://github.com/rubygems/rubygems/commit/dc7c9f029a
|
|
https://github.com/rubygems/rubygems/commit/508ed917a5
|
|
This was an offramp for generated etags to allow existing caches
to be served until people could upgrade. It has been about 6 months
since the transitional version was released, so we can remove this
transitional code now.
https://github.com/rubygems/rubygems/commit/4ec8cfe611
|
|
https://github.com/rubygems/rubygems/commit/022eb473f8
|
|
https://github.com/rubygems/rubygems/commit/592a2fcd54
|
|
If `cache_all_platforms` setting is enabled, the secondary source was
no longer considering cached gems.
That means that if the remote secondary source has removed its gems,
then this was now resulting in an error while before the previously
cached gem from the source would still be used.
This commit restores previous behavior.
https://github.com/rubygems/rubygems/commit/2d2cd00255
|
|
https://github.com/rubygems/rubygems/commit/6166e4bce1
|
|
https://github.com/rubygems/rubygems/commit/5d03a346ab
|
|
I'm not sure why but this particular change seems to have introduced
some flaky test failures. So I'll revert it.
https://github.com/rubygems/rubygems/commit/668488014b
|
|
https://github.com/rubygems/rubygems/commit/de4650f629
|
|
https://github.com/rubygems/rubygems/commit/8c8aaecc48
|
|
If one upgrades the default copy of Bundler through `gem update
--system`, and then reinstalls Ruby without removing the previous copy.
Then the new installation will have a correct default bundler gemspec,
but a higher copy installed in site_dir.
This causes a crash when running Bundler and prints the bug report
template.
This could probably be fixed in Ruby install script, by removing any
previous Bundler default copies, but if the problem is already there, I
think it's best to print a proper user error.
https://github.com/rubygems/rubygems/commit/ada6de765d
|
|
We should make sure Bundler does not trigger RubyGems require logic for
gem activation until it had the chance to register its own monkeypatches
to RubyGems.
https://github.com/rubygems/rubygems/commit/fbd2ff86b9
|
|
https://github.com/rubygems/rubygems/commit/07022e3f2f
|
|
https://github.com/rubygems/rubygems/commit/9ee7069841
|
|
To make sure we can always update to the latest resolvable version for
each gem explicitly requested for update, we first run a full update,
and then add explicit exact requirements to the resolved versions. This
may lead into conflicts, but our resolver already automatically parses
those and unlocks additional gems to fix them.
https://github.com/rubygems/rubygems/commit/01c0bf34f0
|
|
https://github.com/rubygems/rubygems/commit/ea43e4c6d7
|
|
Since resolution options don't change.
https://github.com/rubygems/rubygems/commit/5c5aa38c06
|
|
https://github.com/rubygems/rubygems/commit/924f87c8a9
|
|
An old platform related bug fix made some existing lockfiles no longer
work because they included invalid platforms. So to make it backwards
compatible, code was added to remove invalid platforms from the lockfile
before resolution. This is skipped though when Gemfile has changed
dependencies because in that case we will be re-resolving anyways.
However, in the `bundle update` case, the detection of "dependencies
have changed" was not actually working making Bundler remove all
platforms and not be able to resolve.
https://github.com/rubygems/rubygems/commit/6452adfd62
|
|
https://github.com/rubygems/rubygems/commit/62be097a32
|
|
https://github.com/rubygems/rubygems/commit/c438c6db2e
|
|
We have some places that already use `bundle config auto_install true`,
ie:
https://github.com/technicalpickles/rubygems/blob/7a144f3374f6a400cc9832f072dc1fc0bca8c724/bundler/lib/bundler/cli.rb#L11
This applies the same logic (copy and pasted) to happen when you
`require "bundler/setup"`.
https://github.com/rubygems/rubygems/commit/bb3c922341
|
|
I apparently did that to fix some issue with case insensitivity but I
didn't add a spec, and I think not upcasing should not cause issues.
https://github.com/rubygems/rubygems/commit/1b6f23275a
|
|
All supported rubies include the fix.
https://github.com/rubygems/rubygems/commit/9d74b699f5
|
|
https://github.com/rubygems/rubygems/commit/5d9bf03c59
|
|
https://github.com/rubygems/rubygems/commit/f6f79f4c37
|
|
https://github.com/rubygems/rubygems/commit/e3d180620c
|
|
https://github.com/rubygems/rubygems/commit/b373b7ed0d
|
|
https://github.com/rubygems/rubygems/commit/e8a363713e
|
|
musl vs gnu case
This case is for not locking things like `arm-darwin-23` when the
lockfile already includes `arm-darwin`, so that we don't infinitely keep
redundant versioned platforms in the lockfile when not necessary.
We detect this with `Gem::Platform#===`. For example,
`Gem::Platform.new("arm-darwin-23") === Gem::Platform.new("arm-darwin")`
but they're not `==`.
However, in the case of `-musl` vs `-gnu`, those act as the platform
"version", but `===` is not commutative for them. This is explained in
`===` docs.
We only want to exclude the local platform in situations when
`Gem::Platform#===` is actually commutative.
https://github.com/rubygems/rubygems/commit/8099c4face
|
|
invocation in specs, add banner text for CLI recommending single quotes
https://github.com/rubygems/rubygems/commit/6d2cf955f9
|
|
Bundler online documentation says that if the gem is located within a subdirectory of a git repository,
you can use the `:glob` option to specify the location of its .gemspec
`gem 'cf-copilot', git: 'https://github.com/cloudfoundry/copilot', glob: 'sdk/ruby/*.gemspec'`
This change allows for equivalent functionality from the bundler CLI
`bundle add cf-copilot --git=https://github.com/cloudfoundry/copilot --glob=sdk/ruby/*.gemspec`
https://github.com/rubygems/rubygems/commit/91052e5868
|
|
This affected both CLI and Gemfile installs
https://github.com/rubygems/rubygems/commit/a0d101a8df
|
|
everything
https://github.com/rubygems/rubygems/commit/1ea44b3749
|
|
https://github.com/rubygems/rubygems/commit/7b5cc51a96
|
|
https://github.com/rubygems/rubygems/commit/6ca192649f
|
|
We just need to filter versions belonging to the range, but don't need
anything else.
https://github.com/rubygems/rubygems/commit/8355a225d7
|
|
https://github.com/rubygems/rubygems/commit/bb5727934c
|
|
So that we don't need to reverse the Array.
https://github.com/rubygems/rubygems/commit/aeea5e2e00
|
|
https://github.com/rubygems/rubygems/commit/ac24a68486
|
|
We do that when first caching versions, and then it's no longer
necessary.
https://github.com/rubygems/rubygems/commit/ede15847db
|
|
https://github.com/rubygems/rubygems/commit/13294528c4
|