| Age | Commit message (Collapse) | Author |
|
- I'd like to be able to see how long bundler takes for basic
operations such as downloading a gem from Rubygems.org and
installing a gem.
It will now be possible with this commit by running
`DEBUG=true bundle install` and have output that looks like:
Fetching rack-test 2.2.0
Downloaded rack-test in: 50.523s
Installing rack-test 2.2.0
Installed rack-test in: : 0.003s
https://github.com/ruby/rubygems/commit/46386d43e1
|
|
- ### Problem
This limit is used when Bundler fallback to getting a dependency
list from a server `/dependencies?gem=` endpoint. Bundler uses
this API endpoint fallback when a server doesn't expose the compact
index API.
This is not used for Rubygems.org, only private servers.
This limit is then divided by the number of dependency to get
and the result is the number of request we'll be doing.
The bottleneck on the client is the network roundtrip. On the
server, getting the info of 50 or 100 gems is a bit more expensive
but this operation is heavily cached.
This is an example of Rubygems.org implementation at the time the
dependencies API wasn't deprecated
https://github.com/rubygems/rubygems.org/blob/5a3a3ec02acc3a4e3aba077953a393ad20a06842/app/models/gem_dependent.rb#L15
### Context
This limit used to be 100 a while ago but got changed
to 50 in https://github.com/ruby/rubygems/commit/e745f8dc901dd419e7dc8aede3e8d49569fc7b1e
I don't know why.
### Solution
50 gems to query seems arbitrary low. By doubling this number, we
make twice as less API requests which ultimately can shove up to two
seconds on application relying on a large number of gems.
https://github.com/ruby/rubygems/commit/831894043c
|
|
https://github.com/rubygems/rubygems/commit/bfe15a4712
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
The previous wording was too specific, there may be situations when the
gem has actually never installed (so never deleted either).
https://github.com/rubygems/rubygems/commit/e4a0d71fbe
|
|
https://github.com/rubygems/rubygems/commit/3df86cd9c6
|
|
https://github.com/rubygems/rubygems/commit/c80998a22a
|
|
https://github.com/rubygems/rubygems/commit/74e8eff779
|
|
included
https://github.com/rubygems/rubygems/commit/b9a2d4d539
|
|
By the time `cached_gem` is called, default gem cache has already been
handled. So no need to try redownload it again, it's enough to check the
cache location directly.
https://github.com/rubygems/rubygems/commit/70e10236b6
|
|
extensions are used
https://github.com/rubygems/rubygems/commit/55649cd09b
|
|
a full unlock
https://github.com/rubygems/rubygems/commit/a8670e43f8
|
|
So that those lockfiles still work with older Bundler versions.
https://github.com/rubygems/rubygems/commit/880275bb66
|
|
any other gem
For backwards compatibility, make sure default gems are still used as a
last resort when materializing, in case no remote, cached, or installed
specs are found.
https://github.com/rubygems/rubygems/commit/93788f689f
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/e8a363713e
|
|
https://github.com/rubygems/rubygems/commit/146de56353
|
|
https://github.com/rubygems/rubygems/commit/5d6a8f2fb4
|
|
This reverts commit https://github.com/rubygems/rubygems/commit/091b4fcf2b99.
https://github.com/rubygems/rubygems/commit/dcade3235f
|
|
If a gem is specified in the Gemfile (or resolved as a transitive
dependency), it's always resolved from remote/installed sources. Default
gems are only used as a fallback for gems not included in the bundle.
I believe this leads to more consistent behavior and more portable apps,
since all gems will be installed to the configured bundle path,
regardless of whether they are default gems or not.
https://github.com/rubygems/rubygems/commit/091b4fcf2b
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Gem::RemoteFetcher uses Gem::Request, which adds the RubyGems UA.
Gem::RemoteFetcher is used to download gems, as well as the full index.
We would like the bundler UA to be used whenever bundler is making
requests.
This PR also avoids unsafely mutating the headers hash on the shared
`Gem::RemoteFetcher.fetcher` instance, which could cause corruption or
incorrect headers when making parallel requests. Instead, we create one
remote fetcher per rubygems remote, which is similar to the connection
segregation bundler is already doing
https://github.com/rubygems/rubygems/commit/f0e8dacdec
|
|
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
https://github.com/rubygems/rubygems/commit/26ceee0e76
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
https://github.com/rubygems/rubygems/commit/86c7084e1c
|
|
Ensure unrecognized SPECS types are ignored
https://github.com/rubygems/rubygems/commit/5b33e91075
|
|
When @allow_cached is true, @allow_local is always true,
therefore, the #installed_specs will always be merged after #cached_specs
is called. This makes starting with installed_specs.dup redundant.
When #cached_specs is called because @allow_remote is true and
@allow_cached is false, then installed_specs will be added after
cached_specs based on @allow_local.
We never need to add installed_specs here, so don't.
https://github.com/rubygems/rubygems/commit/49b38f9750
|
|
Rename Index#use(override = true) to #merge!
Rename Index @all_specs to @duplicates, it is not actually all specs.
@duplicates only holds specs that would have been overridden during a call to
Index#use or Index#merge!
Reduced dupes in @duplicates by not double adding the new spec to the
index and the @duplicates during #merge!
Reduce Array creation by using specialized methods when the one result
or no results are needed from the search.
https://github.com/rubygems/rubygems/commit/47e91125db
|
|
override = false
https://github.com/rubygems/rubygems/commit/790202691d
|
|
https://github.com/rubygems/rubygems/commit/d66815633b
|
|
remote gemfiles
If a legacy multi remote Gemfile depends transitively on a default gem,
then in standalone mode we'd fail to fetch the proper version from the
source that includes it, since we were adding it to `specs` (instead of
`remote_specs`), which was already including the default version of the
gem, and thus preventing the remote version from "overwriting that" and
being added to the index. We should add it to the `remote_specs` index
directly instead.
https://github.com/rubygems/rubygems/commit/05f4f9dfc0
|
|
https://github.com/rubygems/rubygems/commit/f664d60114
|
|
On legacy Gemfiles with multiple remote sources, where all of them
support the compact index API, we were still falling back to full
indexes.
Fixing this also allows to simplifying the code.
https://github.com/rubygems/rubygems/commit/b1357c8e72
|
|
https://github.com/rubygems/rubygems/commit/93f74abc5f
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
It's the only part that needs "root folder resultion" to figure out the
folder for the cache, but it's only needed for some things, so run that
logic lazily when needed.
https://github.com/rubygems/rubygems/commit/c7b9eae0bc
|
|
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
|
|
Just like gem sources, a "style-only" change, like adding a trailing
slash, should not expire them.
|
|
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
from https://github.com/rubygems/rubygems/commit/bfb0ae69776069155d2092702bfbb5a12617d85a
Notes:
Merged: https://github.com/ruby/ruby/pull/6906
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6330
|
|
https://github.com/rubygems/rubygems/commit/16c3535413afebcdbab7582c6017c27b5da8a8dc
Notes:
Merged: https://github.com/ruby/ruby/pull/6326
|
|
https://github.com/rubygems/rubygems/commit/b93d4de2ff
|
|
https://github.com/rubygems/rubygems/commit/6aa4c422a7
|
|
This is a regression from https://github.com/rubygems/rubygems/commit/cf749f8ffabd. The
funny thing is that we have a spec for this feature, so it was unclear
how we regressed here. It turns out there was a bug in one of our
negative matchers checking that gems ARE NOT included in a bundle.
This commit fixes the bug in the negative matcher and reverts
https://github.com/rubygems/rubygems/commit/cf749f8ffabd (with a slightly simpler diff).
https://github.com/rubygems/rubygems/commit/3f9a4ff32a
|
|
specification
Previously we would instantiate two different packages and extract the
specification from the package twice for each gem installed. We can
reuse the installer for this so that we just need to do it once.
https://github.com/rubygems/rubygems/commit/e454f850b1
|
|
https://github.com/rubygems/rubygems/commit/ba975b3b7f
|
|
https://github.com/rubygems/rubygems/commit/600a9ac658
|
|
This is the explanation of why we do the swapping, not of why we
download the gem.
https://github.com/rubygems/rubygems/commit/1a25eb7e7b
|
|
installer
https://github.com/rubygems/rubygems/commit/796eebfdbf
|