Age | Commit message (Collapse) | Author |
|
https://github.com/rubygems/rubygems/commit/146de56353
|
|
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Currently, auto-install with git gems fails, when
it would succeed with a rubygems-source gem
Fix the issue by doing the same fallback for git errors as we do for
missing gems, the git errors should only bubble up in these cases when
the gem is not installed, meaning we want to go through the install flow
(and any persistent errors will be raised through there)
https://github.com/rubygems/rubygems/commit/e25a339f7a
|
|
https://github.com/rubygems/rubygems/commit/93619c97ff
|
|
https://github.com/rubygems/rubygems/commit/258476c38a
|
|
https://github.com/rubygems/rubygems/commit/085d2776d8
|
|
missing gems
If the original `BUNDLE_GEMFILE` is different from the default, then the
suggestion wouldn't work as is.
Before:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install` to install missing gems.
$ rubygems git:(better-cmd-suggestion) ✗ bundle install
Could not locate Gemfile
```
After:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb` to install missing gems.
$ bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb
Fetching gem metadata from https://rubygems.org/.........
Using ast 2.4.2
Using bundler 2.4.7
Using parser 3.1.2.0
Using rainbow 3.1.1
Using parallel 1.22.1
Using regexp_parser 2.5.0
Using rubocop-ast 1.18.0
Using rexml 3.2.5
Using ruby-progressbar 1.11.0
Using unicode-display_width 2.1.0
Fetching rubocop 1.30.1
Installing rubocop 1.30.1
Using rubocop-performance 1.14.2
Bundle complete! 2 Gemfile dependencies, 12 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ util/rubocop
Inspecting 345 files
.........................................................................................................................................................................................................................................................................................................................................................
345 files inspected, no offenses detected
```
https://github.com/rubygems/rubygems/commit/bf1320d805
|
|
Pick from https://github.com/rubygems/rubygems/commit/e9304aed7e43308b99e70c2f7b92028315fee8a5
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5606
|
|
https://github.com/rubygems/rubygems/commit/f481e8f41a
|
|
Use a more standard naming for gems.
https://github.com/rubygems/rubygems/commit/75121e83f1
|
|
Merge from https://github.com/rubygems/rubygems/commit/793ad95ecb40e84a1dcb4cb60f2686843ed90de5
Notes:
Merged: https://github.com/ruby/ruby/pull/5265
|
|
Picked from https://github.com/rubygems/rubygems/commit/4b498709a015a94e14a3852a1841a7a3e669133d
|
|
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.
https://github.com/rubygems/rubygems/commit/30eb14f853
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
Bundler formatters already take care of this.
https://github.com/rubygems/rubygems/commit/c24415fdd5
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
This is in preparation for deprecating source-less gemfiles.
https://github.com/rubygems/rubygems/commit/d6493fa3e2
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4648
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4143
|
|
55634a8af18a52df86c4275d70fa1179118bcc20
Notes:
Merged: https://github.com/ruby/ruby/pull/4021
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3982
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3901
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3864
|
|
https://github.com/rubygems/rubygems/commit/27e0e4ecb6
Notes:
Merged: https://github.com/ruby/ruby/pull/3275
|
|
https://github.com/rubygems/rubygems/commit/e3f60d8aec
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/4d1a0c465a
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/746a4b3d74
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/ade0c441d5
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
This command is failing because of the same reason that the subsequent
`bundle exec` is failing: the gemspec is invalid. The `bundle install`
here deviates the `bundle exec` focus from the test and is unnecessary:
all we need is a `Gemfile` that will trigger the `bundle exec`, so let's
create and avoid the extra command.
https://github.com/rubygems/rubygems/commit/eb83cf6cf1
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
I'm guessing the commands under ruby-core setup are very long, so the
title gets truncated. Use a shorter title, since the test doesn't really
care.
Notes:
Merged: https://github.com/ruby/ruby/pull/3225
|
|
The `gem_command` helper was failing to require `support/hax.rb`, which
takes care of making sure rubygems actually picks up the right `ruby`
executable under ruby-core setup (`ENV["RUBY"]`). This caused binstubs
to be generated with a wrong shebang, and that caused `bundle exec` to
not work. The error message was pretty confusing though due to
https://bugs.ruby-lang.org/issues/16952.
Notes:
Merged: https://github.com/ruby/ruby/pull/3225
|
|
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`.
https://github.com/rubygems/rubygems/commit/3d5e186241
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3114
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3114
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3114
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3114
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3086
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3086
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3086
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/2753
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/2753
|
|
Features:
- Add caller information to some deprecation messages to make them easier to fix [#7361](https://github.com/bundler/bundler/pull/7361)
- Reconcile `bundle cache` vs `bundle package` everywhere. Now in docs, CLI help and everywhere else `bundle cache` is the preferred version and `bundle package` remains as an alias [#7389](https://github.com/bundler/bundler/pull/7389)
- Display some basic `bundler` documentation together with ruby's RDoc based documentation [#7394](https://github.com/bundler/bundler/pull/7394)
Bugfixes:
- Fix typos deprecation message and upgrading docs [#7374](https://github.com/bundler/bundler/pull/7374)
- Deprecation warnings about `taint` usage on ruby 2.7 [#7385](https://github.com/bundler/bundler/pull/7385)
- Fix `--help` flag not correctly delegating to `man` when used with command aliases [#7388](https://github.com/bundler/bundler/pull/7388)
- `bundle add` should cache newly added gems if an application cache exists [#7393](https://github.com/bundler/bundler/pull/7393)
- Stop using an insecure folder as a "fallback home" when user home is not defined [#7416](https://github.com/bundler/bundler/pull/7416)
- Fix `bundler/inline` warning about `Bundler.root` redefinition [#7417](https://github.com/bundler/bundler/pull/7417)
Notes:
Merged: https://github.com/ruby/ruby/pull/2668
|
|
Maybe it has fixed at 5a384e2c08704dc7af9d8d3bdfc475eb8c0723aa
Notes:
Merged: https://github.com/ruby/ruby/pull/2399
|
|
* 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
|
|
If we use system bundler, when booting the "outermost" bundler process,
bundler will save the path to the system bundler in BUNDLE_BIN_PATH, and
use it again when booting the "innermost" bundler process (`bundle exec
echo foo`).
That means that second process will use the system bundler path again.
However, we have `-rsupport/hax` in RUBYOPT, so that file will load from
the local copy of bundler, and that file will load `bundler/version`
from the project (not from system), because -Ilib is in the LOAD_PATH.
That will end up causing redefinition errors because the same constant
will be loaded from two different locations.
In general, this is expected behavior, normally you will wrap the
process with `Bundler.with_original_env` to reset the environment.
However, the easiest fix here is to not use system bundler, because it's
not really necessary and thus doesn't help the readability of the spec.
https://github.com/bundler/bundler/commit/a3d72a34ab
|
|
https://github.com/bundler/bundler/commit/789dd1864f
|
|
https://github.com/bundler/bundler/commit/79fdebd868
|
|
https://github.com/bundler/bundler/commit/afdacd62ac
|
|
failing tests for ruby < 2.6"
This reverts commit e63e844bc7444c6a489fcde0dc7011c6c4807edd.
It was introduced to resolve some failing tests at the cost of making
the intention of the spec much less clear.
Thanks to the previous fixes we have added to this spec, we can revert
that patch now.
https://github.com/bundler/bundler/commit/b29a40820f
Notes:
Merged: https://github.com/ruby/ruby/pull/2366
|