`version` is actually an attribute of the dependency, not of the git
source. Sometimes it's passed to the git source to be able to fake a
gemspec in case there's no gemspec in the source, but it should not be
used for source comparison.
d936fbd78e
Specs that use extension gems were failing in the new job but I noticed
that they were using very non standard `extconf.rb` files.
The hack being removed here was added just to make specs pass when run
in ruby-core but it seems the underlying issue has been fixed now, and
it's causing issues with Ruby 3.3 and Windows, so necessary so I'm
removing it and moving on.
5b78275f0e
Previously, when sorting and comparing git Gemfile vs lockfile sources during
`bundler/setup` to figure out whether we need to re-resolve or not, we
would try to find the default branch if nothing more specific was
specified in the Gemfile.
If the git cache has been deleted thought, that would fail.
The error would still be swallowed (and the branch would simply not be
displayed), but trying to clone would still generate the side effect of
creating the parent folder for the clone.
That could affect non-writable systems that don't expect `bundler/setup`
to write to the filesystem at all.
To fix this, override `Bundler::Source::Git#identifier` to use
exclusively static information, so it does not even try to clone the
repo nor generate any side effects.
582eb2ef39
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
This doesn't affect the outcome of the test, but it makes the `git
commit` command inside `update_git` not fail because of not having
anything to commit.
ad0160ed97
The commands these specs run were throwing warnings in bundler 2, and
failing on bundler 3, effectively testing a different scenario to what
they were supposed to.
97ac1ced49
Instead, use the non-deprecated option except when specifically testing
deprecated CLI flags. In that case, pass the flag directly and limit
the specs to `bundler < 3`.
3d5e186241
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
