Running everything in `bundled_app` by default causes the `bundled_app`
helper to be used everytime, and that will create a scoped bundled_app
folder if it does not exist. That causes `bin/rake spec:deps` to create
an empty `tmp/2.1/bundled_app` folder which is a bit weird.
This commit changes specs to not switch to a (possibly empty)
bundled_app directory when not necessary (for example, when running
`gem` commands in order to setup test dependencies).
4bf89c0705
Originally, all the specs in this file were put inside a shared examples
block, and since then all specs were run only changing the cwd (either
from root, or a subdirectory).
This was in d7291700d0, to cover a fix in
the `bundler_path` method.
However, reverting that fix does not make any of the specs in either of
the main blocks fail! Only an unrelated spec of `bundle install
--standalone --local` fails.
The reason is that all specs set `path` to an absolute path, making the
fix essentially uncovered.
In order to simplify the file structure and improve runtime, I
completely removed the shared examples block, and only run main specs
for the root directory. Then I added a couple of extra specs to cover
the original bug fix.
This cuts runtime of this spec file in half, from 1m30s to 45s on my
laptop.
cc506f17e0
Since now every functionality that changes in Bundler 4 is under a
setting, we can enable that setting to test the new functionality,
without having to run our full CI twice.
This can actually be seen as increasing coverage, because Bundler 4
functionality will now be tested on Windows, MacOS, or any other
environment where previously "Bundler 4 mode" was not running.
1cb3e009fc
It was not properly being detected as an Array attribute, and thus not
properly validated.
Fixing this allows us to remove a strange `rescue` clause in Bundler.
4121a32408
As discussed in https://github.com/rubygems/rubygems/issues/6273#issuecomment-1449176658
The `gem` method behaves awkwardly in standalone mode. Assuming bundler
isn't loaded at all, a call to gem might activate a gem that is not part
of the bundle (because it's the gem method defined in
lib/rubygems/core_ext/kernel_gem.rb and not
lib/bundler/rubygems_integration.rb). And when running with
`--disable-gems`, the gem method won't be defined at all so we'll get a
NoMethodError.
Calls to `gem` can appear in dependencies outside an application's
control. To work around this at GitHub we defined our own `Kernel#gem`
that no-ops.
I agree with https://github.com/rubygems/rubygems/issues/6273#issuecomment-1440755882
> people using standalone mode don't want to activate gems like Kernel.gem
This commit redefines `Kernel#gem` in the standalone script to no-op.
bea17b55f1
I'm not sure if using relative paths in the generated script is best for
this case, since it makes the script not movable, but that can be
improved later.
7f5bdbb842
When testing under the ruby/ruby setup, mkmf.rb needs to the `$extout`
global variable set properly.
This is because, in this particular case, the `ruby.h` header needed to
compile extensions is constructed from
`$(extout)/include($arch)/ruby/config.h` but `$extout` is not set by
default.
I tried to fix this in mkmf.rb itself but I couldn't figure it. But
setting it externally to workaround the issue fixes the specs, so I'll
start with that. Also setting it externally causes issues when running
specs upstream against Ruby 2.3 (I guess because of some difference with
Ruby 2.3 mkmf.rb implementation). So I'm avoiding doing it on Ruby 2.3 to
woraround that.
d782984585
The paths for extensions of gems would contain the hardcoded ruby
version on which the extension was built. This will replace it with
runtime ruby version like the parent version directory. It will make the
standalone script compatible between different ruby version installations.
a9dae93d5d
The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.
Fix the accessor to properly update the underlying full specification.
efa41babfa
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>
