| Age | Commit message (Collapse) | Author |
|
Bundler::CompactIndexClient::Cache#versions
String#split supports a block since Ruby 2.6, avoiding intermediate array.
https://github.com/rubygems/rubygems/commit/4e864a8f2e
|
|
Bundler::YAMLSerializer#load
String#split supports a block since Ruby 2.6, avoiding intermediate array.
https://github.com/rubygems/rubygems/commit/5b324969cd
|
|
The same array was being re-created in a loop (as well as the `generic_local_platform`), which is avoidable by hoisting it to a frozen array created once
https://github.com/rubygems/rubygems/commit/009a3c6d0d
|
|
Generally the removed message is very similar, but often it needs to
specify that the feature has "been removed" instead of "will be
removed", or "been deprecated". And a few chunks of text needed more
substantial updates. And a number of them seemed to have been carefully
crafted to make sense in either context, so I left those alone.
https://github.com/rubygems/rubygems/commit/8d42cf9104
|
|
If supplied, it uses that in place of the message for the case where the
deprecation version is already past.
https://github.com/rubygems/rubygems/commit/1deb73663c
|
|
Currently, auto-install with git gems fails, when
it would succeed with a rubygems-source gem
Fix the issue by doing the same fallback for git errors as we do for
missing gems, the git errors should only bubble up in these cases when
the gem is not installed, meaning we want to go through the install flow
(and any persistent errors will be raised through there)
https://github.com/rubygems/rubygems/commit/e25a339f7a
|
|
Pathname::SEPARATOR_PAT is a constant and can safely be interpolated once, avoiding creating a new regexp object on every iteration
https://github.com/rubygems/rubygems/commit/75d9c0f1e4
|
|
https://github.com/rubygems/rubygems/commit/46f09800da
|
|
This changes the CompactIndexClient to store etags received from the
compact index in separate files rather than relying on the MD5 checksum
of the file as the etag.
Smoothes the upgrade from md5 etags to opaque by generating them when no
etag file exists. This should reduce the initial impact of changing the
caching behavior by reducing cache misses when the MD5 etag is the same.
Eventually, the MD5 behavior should be retired and the etag should be
considered completely opaque with no assumption that MD5 would match.
|
|
https://github.com/rubygems/rubygems/commit/9ab1136036
|
|
https://github.com/rubygems/rubygems/commit/59a66e3560
|
|
message
https://github.com/rubygems/rubygems/commit/cb4e26eabc
|
|
deprecation message
https://github.com/rubygems/rubygems/commit/3fd627e486
|
|
Configuration is now local by default.
https://github.com/rubygems/rubygems/commit/6bc7709aa8
|
|
bundle-install.1.ronn
https://github.com/rubygems/rubygems/commit/e956c5bbe4
|
|
```
==> memprof.after.txt <==
Total allocated: 1.13 MB (2352 objects)
Total retained: 10.08 kB (78 objects)
==> memprof.before.txt <==
Total allocated: 46.27 MB (38439 objects)
Total retained: 9.94 kB (75 objects)
```
Yes, we were allocating 45MB of arrays in `dependencies_installed?`,
it was accidentally cubic.
https://github.com/rubygems/rubygems/commit/13ab874388
|
|
https://github.com/rubygems/rubygems/commit/97ee203fd5
|
|
json-parseable output
https://github.com/rubygems/rubygems/commit/65efa44bc0
|
|
repetition
We're about to expand the repeated bit of code, so drying it up a little
is warranted.
https://github.com/rubygems/rubygems/commit/e69c658be6
|
|
If a platform specific variant would not match the current Ruby, we would still be
considering it compatible with the initial resolution and adding its
platform to the lockfile, but we would later fail to materialize it for
installation due to not really being compatible.
Fix is to only add platforms for variants that are also compatible with
current Ruby and RubyGems versions.
https://github.com/rubygems/rubygems/commit/75d1290843
|
|
https://github.com/rubygems/rubygems/commit/4ce66c41a2
|
|
|
|
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
|
|
This is also done in bundler/lib/bundler/rubygems_integration.rb, but
bundler/lib/bundler.rb loads this file before it.
https://github.com/rubygems/rubygems/commit/8840d8507b
|
|
If a Gemfile duplicates a development dependency also defined in a local
gemspec with a different requirement, the requirement in the local
gemspec will be silently ignored.
This surprised me.
I think we should either:
* Make sure both requirements are considered, like it happens for
runtime dependencies (I added a spec to illustrate the current behavior
here).
* Add a warning that the requirement in the gemspec will be ignored.
I think the former is slightly preferable, but it may cause some
bundle's that previously resolve to no longer resolver.
I went with the latter but the more I think about it, the more this
seems like it should behave like the former.
https://github.com/rubygems/rubygems/commit/ad6843972f
|
|
https://github.com/rubygems/rubygems/commit/3c1a6a7dfa
|
|
https://github.com/rubygems/rubygems/commit/9509d98b5c
|
|
https://github.com/rubygems/rubygems/commit/70243b1d72
|
|
https://github.com/rubygems/rubygems/commit/93619c97ff
|
|
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
|
|
full spec
https://github.com/rubygems/rubygems/commit/957d3d9a7f
|
|
https://github.com/rubygems/rubygems/commit/8f7340df8e
|
|
https://github.com/rubygems/rubygems/commit/53e0490b55
|
|
https://github.com/rubygems/rubygems/commit/05120e2fe8
|
|
This is a step forward towards eventually including metadata in the
lockfile.
https://github.com/rubygems/rubygems/commit/56fc02b251
|
|
https://github.com/rubygems/rubygems/commit/2462c8e04d
|
|
Since #6945 the extension dir changed to Gem::BasicSpecification's implementation, we didn't hook that in rubygems_ext.rb. So for universal rubies, we ended up using the universal platform name when installing, but arch replaced platform name when checking. This lead to native extensions can never be correctly installed on universal rubies.
Hook Gem::BasicSpecifications so the behavior is consistent on installing and checking.
https://github.com/rubygems/rubygems/commit/8d699ed096
|
|
https://github.com/rubygems/rubygems/commit/625b8293f7
|
|
https://github.com/rubygems/rubygems/commit/5f90a43635
Co-authored-by: Martin Emde <martin.emde@gmail.com>
|
|
https://github.com/rubygems/rubygems/commit/e41156e272
|
|
It's a `BundlerError`.
https://github.com/rubygems/rubygems/commit/53ea676dab
|
|
https://github.com/rubygems/rubygems/commit/abd91ca2e5
|
|
writable bit
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
https://github.com/rubygems/rubygems/commit/4bced7ac73
|
|
it was a performance improvement only, but it causes failures in
unrelated tests
https://github.com/rubygems/rubygems/commit/b4149cb9bf
|
|
Useful if your plugin introduces new methods to the DSL, so that
Gemfiles can easily abort if the plugin hasn't loaded yet
https://github.com/rubygems/rubygems/commit/b733055c6e
|
|
https://github.com/rubygems/rubygems/commit/8d51390ca4
|
|
EndpointSpecification
Not strictly necessary, but there is no reason not to be helpful and set the path
https://github.com/rubygems/rubygems/commit/894c0303dd
|
|
Gem::Specification#files
https://github.com/rubygems/rubygems/commit/4bb0ef3e55
|
|
https://github.com/rubygems/rubygems/commit/7c0afdd9af
|
|
https://github.com/rubygems/rubygems/commit/9b61b33568
|