| Age | Commit message (Collapse) | Author |
|---|
|
Prism will be the parser in Ruby 3.3. We need to support 3.0+ so we will have to "dual boot" both parsers.
Todo:
- LexAll to support Prism lex output
- Add tests that exercise both Ripper and prism codepaths on CI
- Handle https://github.com/ruby/prism/issues/1972 in `ripper_errors.rb`
- Update docs to not mention Ripper explicitly
- Consider different/cleaner APIs for separating out Ripper and Prism
https://github.com/ruby/syntax_suggest/commit/a7d6991cc4
|
|
gemspec
https://github.com/rubygems/rubygems/commit/e78c0a4a48
|
|
https://github.com/ruby/syntax_suggest/commit/73753518e9
|
|
https://github.com/ruby/syntax_suggest/commit/2771dcabe0
|
|
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
|
|
|
|
|
|
|
|
|
|
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
|
|
deprecation message
https://github.com/rubygems/rubygems/commit/3fd627e486
|
|
Configuration is now local by default.
https://github.com/rubygems/rubygems/commit/6bc7709aa8
|
|
https://github.com/rubygems/rubygems/commit/ed4eaefac0
|
|
```
==> 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
|
|
json-parseable output
https://github.com/rubygems/rubygems/commit/65efa44bc0
|
|
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/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
|
|
https://github.com/rubygems/rubygems/commit/7ab4c203f9
|
|
https://github.com/rubygems/rubygems/commit/53e0490b55
|
|
Otherwise you can have work in some circumstance but not in others.
|
|
Daily Bundler CI against ruby-head is failing because ruby-head now
uses bigdecimal 3.1.5, so that gets locked by this spec.
This change should make the test stable until bigdecimal 99.1.5 is
bundled with Ruby :)
https://github.com/rubygems/rubygems/commit/830326041f
|
|
in Bundler specs
We want to avoid any "user home" fallbacks, since that won't work with
Bundler.
So if there's a permissions issue during specs, it's best to raise
immediately.
https://github.com/rubygems/rubygems/commit/767a3e7533
|
|
This command is not expected to fail. If it fails, we can stop the test.
https://github.com/rubygems/rubygems/commit/2511a5b093
|
|
https://github.com/rubygems/rubygems/commit/2eb2860e9e
|
|
foo.gemspec was added in
rubygems/rubygems@8d699ed096960ed9a6636bd27143952ff5f8addc but was not
sync'd in commit b4bf8c9ee2d716adf5fc08e67c4b26d6a8f929c2. This causes
the spec to fail.
|
|
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
|
|
Comparing file paths as strings may not work well for some reasons,
symlink, relative `__FILE__`, etc.
Some alternatives are possible: comparing with `File.realpath`, or
with `File.identical?`, it should be most robust to escape the target
string contained within this file itself.
|
|
https://github.com/rubygems/rubygems/commit/3e7f1379fb
|
|
https://github.com/rubygems/rubygems/commit/e41156e272
|
|
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
|
|
|
|
LibreSSL seems not to support `scrypt`.
https://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20231105T233005Z.fail.html.gz
```
1)
OpenSSL::KDF.scrypt creates the same value with the same input ERROR
NoMethodError: undefined method `scrypt' for module OpenSSL::KDF
```
|
|
https://github.com/rubygems/rubygems/commit/8d51390ca4
|
|
|
|
Do not use a variable as a format string. Also we usually don't
expect non-ascii data in C string literals.
|
|
|
|
|
|
This reverts commit d434765faead1583ca9008bb579067a288085b93.
|
|
|
|
|
