The `initialize` method is already doing a lot and by adding the `Gem::PrintableUri` to redact sensitive information, things are getting complicated and hard to read here. For the start, I have refactored the `initialize` method into a class method called `build`.
https://github.com/rubygems/rubygems/commit/4312e8fdf5
The `@uri` variable could be a source URI with a credential. Using `Gem::PrintableUri` to make sure we are redacting sensitive information from it when logging on verbose mode.
https://github.com/rubygems/rubygems/commit/f566787211
The error had not be caught be specs because `bundle install` was
returning a zero exit code when plugin installation errors happened. So
I fixed that issue too.
https://github.com/rubygems/rubygems/commit/90cde87856
As part of a recent bug fix where bundler was accidentally hitting the
network when not supposed to, I made some refactoring, and the commit I'm
reverting here
(d74830d00b)
was some cleanup that those refactorings allowed according to "past me".
That was completely wrong, `bundle check` should never consider cached
gems, only installed gems, so the code that was removed was necessary.
https://github.com/rubygems/rubygems/commit/5483e98305
Use the `git branch --list` rather than the `git branch -l` for better
compatibility. Because the `git branch -l` is used to create a new branch in
Git version < 2.20.0.
https://github.com/rubygems/rubygems/commit/eac5be7d06
We think it's unlikely that `rubygems/defaults/operating_system` could be shipped with a SyntaxError so StandardError could be better choice to prevent "false positives" errors.
https://github.com/rubygems/rubygems/commit/1f73e784dd
When loading `rubygems/defaults/operating_system`
- we want to keep it silent if the raised exception is a LoadError
- we want to print a message in other cases and ask users to report the issue to their OS support.
Ruby 3 comes with special error handling for loading `rubygems` and it will show a warning when LoadError exception raised for requiring 'rubygem'.
Because of that, we decided to leave the LoadError scenario as it is.
Reference: d1998d8767/gem_prelude.rb (L1-L5)https://github.com/rubygems/rubygems/commit/0a97e12fe1
When setting the `RUBYGEMS_GEMDEPS` environment variable to allow
skipping `bundle exec`, `bundler` will print a warning about potential
incompatibility.
Initially the `RUBYGEMS_GEMDEPS` variable used a completely different
(re)implementation of `bundler` functionality. That implementation was
not battle tested and could potentially differ in behaviour from what
`bundler` does. That's why print a warning.
However, these days, all `rubygems` does when `RUBYGEMS_GEMDEPS` is set
is to require `bundler/setup`, so there's no risk of any
incompatibility, since that's just plain `bundler`.
https://github.com/rubygems/rubygems/commit/bbddc27016
Otherwise CI will run once for every pull request update and once for
every push.
The disavantage is that people working on a non default branch without
creating pull requests won't get CI run at all.
I think the advantages are greater than the disadvantages, it's also my
personal workflow, and it's something desired enough so that someone
opened an issue about it.
So let's do it!
https://github.com/rubygems/rubygems/commit/924d916a73
Co-authored-by: NeimadTL <damientalbot26@gmail.com>
As far as I understand, this block should only be run when
`bundler/setup` fails. The only other case where these errors could be
run is when bundler itself is required.
If bundler itself fails to be required or activated (like in old rubies
where it was not a default gem, for example), the raw error is much more
helpful than this message.
So we can move the rescue after bundler is succesfully required, and
that simplifies the list of exceptions that we need to track to just
`Bundler::Error`.
https://github.com/rubygems/rubygems/commit/3663c11e93
Daniel Niknam
Matt Larraz
David Rodríguez
Jun Aruga