| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
https://github.com/ruby/rubygems/commit/bb4d791cb4
|
|
|
|
This allows you to specify the lockfile to use. This is useful if
you want to use different lockfiles for different ruby versions or
platforms. You can also skip writing the lockfile by using a false
value.
https://github.com/ruby/rubygems/commit/2896aa3fc2
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
- ### Problem
When you have a Gemfile that contains git gems, each repository will
be fetched one by one. This is extremelly slow.
A simple Gemfile with 5 git gems (small repositories) can take up
to 10 seconds just to fetch the repos.
We can speed this up by running multiple git process and fetching
repositories silmutaneously.
### Solution
The repositories are fetched in Bundler when `Source::Git#specs` is
called.
The problem is that `source.specs` is called in various places
depending on Gemfile.
I think the issue is that calling `source.specs` feels like that
as a "side effect" we are going to clone repositories. I believe
that fetching repositories should be an explicit call.
For instance:
```ruby
source "https://rubygems.org"
gem "foo", github: "foo/foo"
# The repository foo will be fetched as a side effect to the call to `source.spec_names`
# https://github.com/ruby/rubygems/blob/6cc7d71dac3d0275c9727cf200c7acfbf6c78d37/bundler/lib/bundler/source_map.rb#L21
```
```ruby
source "https://rubygems.org"
gem "bar", source: "https://example.org"
gem "foo", github: "foo/foo"
# The repository foo will be fetched on a different codepath
# https://github.com/ruby/rubygems/blob/6cc7d71dac3d0275c9727cf200c7acfbf6c78d37/bundler/lib/bundler/source/rubygems_aggregate.rb#L35
# That is because the gem "bar" has a source that doesn't have the `/dependencies` API
# endpoint and therefore Bundler enters a different branch condition.
```
I opted to add a self explanatory call to fetch the git source
repositories just before we start the resolution, and *just*
before any other calls to `source.specs` is performed.
https://github.com/ruby/rubygems/commit/f0ef526f23
|
|
- ### Problem
Running `bundle lock --add-checksums` doesn't add the checksum of
gems hosted on server that don't implement the compact index API.
This result in a lockfile which is unusable in production as
some checksums will be missing and Bundler raising an error.
Users can work around this problem by running:
`BUNDLE_LOCKFILE_CHECKSUMS=true bundle install --force`
But this means redownloading and installing all gems which isn't
great and slow on large apps.
### Context
Bundler uses the Compact Index API to get the checksum of gems,
but most private gem servers don't implement the compact index API
(such as cloudsmith or packagecloud). This results in a soft failure
on bundler side, and bundler leaving out blank checksum for those
gems.
### Solution
For gems that are hosted on private servers that don't send back
the checksum of the gem, I'd like to fallback to the
`bundle install` mechanism, which don't rely on an external API but
instead compute the checksum of the package installed on disk.
This patch goes through the spec that didn't return a checksum,
and compute one if the package exists on disk.
This solution makes the `bundle lock --add-checksums` command
actually usable in real world scenarios while keeping the
`bundle lock` command fast enough.
https://github.com/rubygems/rubygems/commit/8e9abb5472
|
|
feature_removed! or feature_deprecated!
https://github.com/rubygems/rubygems/commit/b1b963b34a
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
|
|
"install_if" git gems:
- Fix https://github.com/rubygems/rubygems/pull/8985
- ### Problem
If you have a Gemfile that contains a `install_if` git gem, it will
be impossible to add other gems in the Gemfile and run
`bundle install`, you'll get a "The git source [...] is not yet
checked out".
### Context
The change that modified this behaviour was in https://github.com/rubygems/rubygems/commit/abbea0cc94dd,
and the issue is about the call to `current_dependencies`.
This call filters out irrelevant dependencies such as the one that
get condtionnally installed. By doing so, we skip over setting
the source based of the lockfile for that dependency
https://github.com/rubygems/rubygems/blob/ade324bdc8ea77b342f203cb7f3929a456d725ed/bundler/lib/bundler/definition.rb#L978
Ultimately, because of this, the dependency source doesn't have
any additional information such as the `revision`. Down the line,
when we end up to converge the spec, Bundler will attempt to get the
revision for that spec but won't be able to because the git source
isn't configured to allow running git operations.
### Solution
Filter out the irrelevant only spec only after we have set its
source.
https://github.com/rubygems/rubygems/commit/d2af439671
|
|
https://github.com/rubygems/rubygems/commit/47c3dc19ee
Co-authored-by: Jonathan Barquero <jonbarlo@hotmail.com>
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
https://github.com/rubygems/rubygems/commit/1bc5e74281
|
|
https://github.com/rubygems/rubygems/commit/4c110d3289
|
|
https://github.com/rubygems/rubygems/commit/0a2f5ed717
|
|
changes
When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.
So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.
https://github.com/rubygems/rubygems/commit/85514e3a1e
|
|
It matches the comment above more naturally and it's consistent with how
the same thing is checked in other places.
https://github.com/rubygems/rubygems/commit/59ec6b4b29
|
|
It sounds like this should apply to all git sources at this point.
https://github.com/rubygems/rubygems/commit/b1817f91de
|
|
https://github.com/rubygems/rubygems/commit/744b35412e
|
|
vendor/cache is empty
https://github.com/rubygems/rubygems/commit/36c5af9156
|
|
`lockfile` flags:
- Ref #8917
- ### Problem
Prior to Bundler 2.5.6, running
`bundle lock --update foo --lockfile Gemfile_bumped.lock` would
update only the foo gem and write the lockfile to the
`Gemfile_bumped.lock`.
In Bundler 2.5.6 and above running the same command, updates
absolutely all gems.
This change is related to #7047
### Solution
We decided to expose the `write_lock` method rather than going
through a complex deprecation cycle of the `lock` method.
This commit applies the same business logic as prios to 2.5.6 where,
we build the definition using the existing lockfile, make changes to
the definition and dump it into the desired lockfile.
https://github.com/rubygems/rubygems/commit/c88f00c41d
|
|
https://github.com/rubygems/rubygems/commit/05199ae0c1
|
|
https://github.com/rubygems/rubygems/commit/d41b8d303c
|
|
specific case
If upgrading `foo` needs an indirect dependency to be downgraded,
Bundler would not be able to upgrade foo.
This is because when calculating the latest resolvable version of foo,
Bundler was still adding lower bound requirements on the locked versions
of all dependencies to avoid downgrades, effectively pinning foo to a
version older than the latest.
To fix this, instead of creating a second "unlocked" definition to
figure out the latest resolvable version, create a second unlocked
resolver, and DO NOT add lower bound requirements to it.
https://github.com/rubygems/rubygems/commit/00cc0ecc69
|
|
Fixes a TODO now that no reports have been reported in a while.
https://github.com/rubygems/rubygems/commit/f10dc84e7b
|
|
there's no lockfile
The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.
https://github.com/rubygems/rubygems/commit/a96afc5351
|
|
https://github.com/rubygems/rubygems/commit/b0983f392f
|
|
This will help centralize wheel platform selection logic eventually
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
|
|
https://github.com/rubygems/rubygems/commit/22f0a07377
|
|
Rails
If you have
```
gem "rails", git: "https://github.com/rails/rails"
```
and then explicitly pin to an older ref, like
```
gem "rails", git: "https://github.com/rails/rails", ref: "https://github.com/rubygems/rubygems/commit/99bacb5aa8e5"
```
Then `bundle install` fails, because locked sources fail to be updated
to use the new source.
This commit fixes the problem by making sure get their source properly
replaced.
https://github.com/rubygems/rubygems/commit/5de8c2e0cf
|
|
platforms
https://github.com/rubygems/rubygems/commit/c39d2f84fd
|
|
incompatible
https://github.com/rubygems/rubygems/commit/282e4a8593
|
|
It handles resolution packages but also other stuff.
https://github.com/rubygems/rubygems/commit/4baec92c20
|
|
Don't mention "Found changes from the lockfile" because that's not
really true in general.
https://github.com/rubygems/rubygems/commit/0181c278e8
|
|
https://github.com/rubygems/rubygems/commit/458fa5dc4c
|
|
have changed
Since we will now add it back if the final resolution is compatible, we
can also get this kind of edge case (`bundle add`) working.
https://github.com/rubygems/rubygems/commit/cdc5ebec77
|
|
Instead, remove them anytime we find dependencies don't match the
lockfile for a platform, and then add them back after resolution if
they ended up being valid.
https://github.com/rubygems/rubygems/commit/220bd77887
|
|
anything
https://github.com/rubygems/rubygems/commit/9fd92ade54
|
|
I don't like traversing the array and modifying it at the same time
while it seems to work.
https://github.com/rubygems/rubygems/commit/6551c74c27
|
|
https://github.com/rubygems/rubygems/commit/a0f7851451
|
|
https://github.com/rubygems/rubygems/commit/4497555023
|
|
missing
https://github.com/rubygems/rubygems/commit/054a0cd76c
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
It's a dependency, not a specification.
https://github.com/rubygems/rubygems/commit/9d78f5aa14
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
Instead of doing an explicit pass, let sources be replaced while checking
if specifications are up to date.
https://github.com/rubygems/rubygems/commit/676271e804
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
Instead of doing an explicit pass to preserve the source from the
Gemfile when it's a `Source::Gemspec`, add a special case to our generic
source replacement method.
https://github.com/rubygems/rubygems/commit/20c8c42380
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
sources
The `converge_dependencies` method already replaces the source of the
dependency with an equivalent source from the Gemfile if possible.
https://github.com/rubygems/rubygems/commit/a449e7ba19
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/58e9bd9962
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/e9f4d1e5c2
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
It reads better this way I think.
https://github.com/rubygems/rubygems/commit/ce9743290d
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/558a4765c7
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
