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)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`.
bbddc27016
Even if it only has one entry at the moment, it makes it easier to add
new entries by doing it this way.
46232fe265
Co-authored-by: NeimadTL <damientalbot26@gmail.com>
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!
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`.
3663c11e93
When printing sources inside these error messages, it's useful to only
consider the current state of the source. For example, when requiring
`bundler/setup`, the source shouldn't be configured to be able to hit
the network, so the error message should only mention "locally installed
gems" to make that more clear.
30eb14f853
In the case of path sources, the path the source is pointing to should
be added directly to the `$LOAD_PATH` without any modifications.
d3bba936f0
Co-authored-by: Daniel Niknam <mhmd.niknam@gmail.com>
Due to the `bundler` gem itself being ignored from `$LOAD_PATHS`, a
`nil` value is being introduced here, resulting in the current folder
being added to the `$LOAD_PATH` by the standalone script.
I'm pretty sure this is unintentional.
df54b07b5e
Since this mode is only enabled in frozen mode, it's fine to use the
lockfile and means we don't have to "prepare" the replacement for
materialization.
dda01b288e
TSort was released as a library so we can install it, and also other
gems that are loaded by the spec. Also, Ruby on Windows apparently loads
fiddle 1.0.6, so we need to also install that to make that not fail.
2b8dcab99e
