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
This makes bundler consistent with all other gems, and makes the default
installation of Bundler in the release package look like any other
bundler installation.
Before (on preview3, for example), Bundler executable is installed at:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/libexec/bundle
Now it's installed in the standard location:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/exe/bundle
The `options[:user_install]` might have three states:
* `true`: `--user-install`
* `false`: `--no-user-install` and
* `nil`: option was not specified
However, this had not been respected previously and the `false` and `nil`
were treated the same. This could lead to auto user installation despite
`--no-user-install` being specified on the command line.
Fixes https://github.com/rubygems/rubygems/pull/7237https://github.com/rubygems/rubygems/commit/9281545474
I think we can safely assume these days that all RubyGems and Bundler
versions that will ever bundle a new gem created in 2023 support
prereleases.
So this non transparent requirement is not necessary.
In my opinion, it should be the gem author to explicitly add this
constraint, not RubyGems.
https://github.com/rubygems/rubygems/commit/b165e6d725
For now, on a small rails app I have hanging around:
```
==> memprof.after.txt <==
Total allocated: 872.51 MB (465330 objects)
Total retained: 40.48 kB (326 objects)
==> memprof.before.txt <==
Total allocated: 890.79 MB (1494026 objects)
Total retained: 40.40 kB (328 objects)
```
Not a huge difference in memory usage, but it's a drastic improvement
in total number of allocations.
Additionally, this will pay huge dividends once
https://github.com/ruby/zlib/pull/61 is merged, as it will allow us to
completely avoid allocations in the repeated calls to readpartial,
which currently accounts for most of the memory usage shown above.
https://github.com/rubygems/rubygems/commit/f78d45d927
Uses Open3.popen2e in place of Open3.capture2e in Gem::Ext::Builder.
This change aims to stream stdout/stderr of ext builds when in verbose
mode, instead of printing everything at once when the build completes.
Nice for debugging gem builds that consumes longer times.
https://github.com/rubygems/rubygems/commit/dcdcb5adda
Before, when requiring "bigdecimal/math" in a Bundler context:
> /Users/deivid/.asdf/installs/ruby/3.3.0-dev/lib/ruby/3.3.0+0/bigdecimal/math.rb:2: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
After:
> foo.rb:1: warning: bigdecimal/math is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
Before, when requiring "bigdecimal" in a Bundler context:
> foo.rb:1: warning: bigdecimal which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
After:
> foo.rb:1: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
https://github.com/rubygems/rubygems/commit/fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Replace use of `STDIN`, `STDOUT` and `STDERR` constants by their
`$stdin`, `$stdout` and `$stderr` global variable equivalents.
This enables easier testing via standard means, such as `assert_output`
for minitest or `expect { print 'foo' }.to output.to_stdout` for RSpec
test suites.
https://github.com/rubygems/rubygems/commit/a0a6fc1b76
Additionally, the result is memoized, as it's used twice in a row.
This change does result in a net behavioral diff, as the list of ENVs
being checked has been updated (now includes buildkite, taskcluster,
cirrus, dsari, and drops buildbox and snap)
https://github.com/rubygems/rubygems/commit/3fb445a5a1
Because bundler needs to support older versions of rubygems, we can't
actually rely on Gem::CIDetector (yet - in a year or so they might be
able to consolidate, if they don't change futher). So we're copying it
into the Bundler:: namespace, and enforcing that they stay completely in
sync with a test. No other tests are needed, since Gem::CIDetector is
already tested, and this is and will remain identical.
https://github.com/rubygems/rubygems/commit/abc67f0da1
This is based on the list in Gem::UpdateSuggestion and Bundler::Fetcher;
these have similar purposes (determining whether/what CI we're executing
in), and can benefit from being combined and updated (they're both
slightly out of date).
Noteable changes:
* We'll consider ourselves to be on a CI in more cases - if CI_NAME or
TASKCLUSTER_ROOT_URL are set specifically, since those represent two
cases that were either overlooked or are no longer covered by the
existing implementation. (Or possibly TaskCluster still does provide
RUN_ID, but failed to document it)
* We will notice/track a few additional services in ci_strings (cirrus,
dsari, taskcluster), stop tracking 'snap' (they went under in 2017),
and update buildbox to buildkite (they've been called that for 8
years, and the BUILDBOX envs have been deprecated for 3).
* We'll also sort/uniq/downcase the values (all of which only matter
because of the special case of CI_NAME).
https://github.com/rubygems/rubygems/commit/60652b942f
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
https://github.com/rubygems/rubygems/commit/2353cc93a4
Before:
```
Expected a newline or semicolon after the statement
Cannot parse the expression
Expected a newline or semicolon after the statement
Cannot parse the expression
1 describe "webmock tests" do
22 it "body" do
27 query = Cutlass::FunctionQuery.new(
> 28 port: port
> 29 body: body
30 ).call
34 end
35 end
```
After:
```
Expected a newline or semicolon after the statement
Cannot parse the expression
1 describe "webmock tests" do
22 it "body" do
27 query = Cutlass::FunctionQuery.new(
> 28 port: port
> 29 body: body
30 ).call
34 end
35 end
```
https://github.com/ruby/syntax_suggest/commit/becf097e5e
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
Previously only unknown word `intern` is allowed between a single-word
token before a C method. Now any single-word token, such as `inline`
which is used for `ArithmeticSequence` in enumerator.c, is allowed
instead.
https://github.com/ruby/rdoc/commit/3a214c1dd1
tomoya ishida
Hiroshi SHIBATA
David Rodríguez
Vít Ondruch
Stan Lo
Martin Emde
Burdette Lamar
Nobuyoshi Nakada
Yusuke Endoh
Samuel Giddins
Franz Liedke
Daisuke Aritomo
Benoit Daloze
Schneems
Akinori MUSHA
Yuji Yaginuma
Kevin Newton
Andrew Kane
Ellen Marie Dash
Eric Mueller
Akshay Birajdar
Toshimaru
Mau Magnaguagno