Age | Commit message (Collapse) | Author |
|
It was printing incorrect output and returning incorrect status.
https://github.com/rubygems/rubygems/commit/96f5979c7d
|
|
https://github.com/rubygems/rubygems/commit/907d46964d
|
|
https://github.com/rubygems/rubygems/commit/3434f094a2
|
|
Currently, an exe file isn't executable when generating new gems
because it doesn't have the correct permission.
This PR sets the correct permission same as files under the `bin`.
https://github.com/rubygems/rubygems/commit/6509bf128a
|
|
`bundle outdated`
Before, `bundle outdated --parseable` (or `--porcelain`) caused output
to be completely silenced during definition resolution, so nothing was
printed at all until the table of outdated gems was printed.
With this change, `--parseable`/`--porcelain` now prints progress to
stderr during resolution. E.g.:
```
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
```
This provides a better user experience, especially when
`outdated --parseable` takes several seconds or more.
The report of outdated gems is still printed to stdout, and the exit
status codes are unchanged, so the fundamental contract with other tools
consuming the `outdated --parseable` result should not be affected.
https://github.com/rubygems/rubygems/commit/7d4bb43570
|
|
--add-platform`
https://github.com/rubygems/rubygems/commit/1f93a2bdc5
|
|
`bundle lock`
`bundle lock --print --update` can take a long time to fetch sources and
resolve the lock file.
Before, `--print` caused output to be completely silenced, so nothing
was printed at all until the resolved lock file is finally emitted to
stdout.
With this change, `--print` now prints progress to stderr. E.g.:
```
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
```
This provides a better user experience, especially when
`lock --print --update` takes several seconds or more.
The lock file is still printed to stdout, so tools consuming the lock
file on stdout will not be affected.
https://github.com/rubygems/rubygems/commit/6719baa700
|
|
frozen being set without a lockfile
https://github.com/rubygems/rubygems/commit/0857d62ca6
|
|
Make `bundle check` exit with code 1 when gem git source is not yet
checked out.
https://github.com/rubygems/rubygems/commit/93162bf5af
|
|
Removes the symlink for gems.rb.tt and instead uses the singular
template file. Only the destination filename for the gemfile reads from
the `init_gems_rb` setting.
https://github.com/rubygems/rubygems/commit/43ce0e1666
|
|
https://github.com/rubygems/rubygems/commit/f58660ffcc
|
|
`current_dependencies` doesn't return gems in optional groups, while `specs` would
Closes https://github.com/rubygems/rubygems/pull/7757
https://github.com/rubygems/rubygems/commit/c797e95636
|
|
https://github.com/rubygems/rubygems/commit/07a5faeb89
|
|
https://github.com/rubygems/rubygems/commit/f9fb413a19
|
|
https://github.com/rubygems/rubygems/commit/5d03a346ab
|
|
Also bring the man page up to date.
https://github.com/rubygems/rubygems/commit/a849bd6947
|
|
It's the exact same implementation as --git
https://github.com/rubygems/rubygems/commit/18eb2418c6
|
|
https://github.com/rubygems/rubygems/commit/6a0c03c77f
|
|
`travis_removal_info` is added by https://github.com/rubygems/rubygems/pull/6150. According to the comment, it's supposed to be removed at bundler v2.5.0 but it hasn't.
https://github.com/rubygems/rubygems/commit/e18797d43f
|
|
since 2.6 and 2.7 are EOL and bundler dropped their support by https://github.com/rubygems/rubygems/pull/7116.
https://github.com/rubygems/rubygems/commit/b562d9a822
|
|
https://github.com/rubygems/rubygems/commit/7cc647c8f3
|
|
https://github.com/rubygems/rubygems/commit/1d61c7686b
|
|
nevinera/add-json-output-option-to-bundle-outdated"
This reverts commit https://github.com/rubygems/rubygems/commit/a4ac5116b8ea, reversing
changes made to https://github.com/rubygems/rubygems/commit/8a6b180d0ae5.
https://github.com/rubygems/rubygems/commit/a1efe4015d
|
|
Improved performance / reduced allocations
https://github.com/rubygems/rubygems/commit/b04726c9a7
|
|
https://github.com/rubygems/rubygems/commit/0e919eaa87
|
|
https://github.com/rubygems/rubygems/commit/fad186df39
|
|
Also fix running when BUNDLE_NO_INSTALL happens to be set, same as with install/update commands
https://github.com/rubygems/rubygems/commit/a555fd6ccd
|
|
https://github.com/rubygems/rubygems/commit/2720da2659
|
|
https://github.com/rubygems/rubygems/commit/fd2e71dfdb
|
|
`minitest` has introduced a rake task for running test on 5.16.0.
https://github.com/minitest/minitest/blob/master/History.rdoc#5160--2022-06-14-
This has some tasks related to running tests and it's useful for
`minitest` user I think.
https://github.com/minitest/minitest#rake-tasks-
This PR changed to use the task in a template file for `minitest`
https://github.com/rubygems/rubygems/commit/7a86d13062
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Generally the removed message is very similar, but often it needs to
specify that the feature has "been removed" instead of "will be
removed", or "been deprecated". And a few chunks of text needed more
substantial updates. And a number of them seemed to have been carefully
crafted to make sense in either context, so I left those alone.
https://github.com/rubygems/rubygems/commit/8d42cf9104
|
|
https://github.com/rubygems/rubygems/commit/97ee203fd5
|
|
json-parseable output
https://github.com/rubygems/rubygems/commit/65efa44bc0
|
|
repetition
We're about to expand the repeated bit of code, so drying it up a little
is warranted.
https://github.com/rubygems/rubygems/commit/e69c658be6
|
|
https://github.com/rubygems/rubygems/commit/70243b1d72
|
|
Gem::Specification#files
https://github.com/rubygems/rubygems/commit/4bb0ef3e55
|
|
The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
https://github.com/rubygems/rubygems/commit/1d501ae8ea
|
|
https://github.com/rubygems/rubygems/commit/bc233af4d2
|
|
https://github.com/rubygems/rubygems/commit/2851e051c3
|
|
To avoid potential crashes when trying to jump from a drive to another
on Windows, and take the change refactor things a bit.
https://github.com/rubygems/rubygems/commit/7c9a9a431a
|
|
When a path does not make a lot of sense.
https://github.com/rubygems/rubygems/commit/d173c79e9a
|
|
Preferring instead to spawn the subprocess in the correct directory
https://github.com/rubygems/rubygems/commit/ad5abd6a45
|
|
It now does the redownloading/installing just like bundle install --redownload
https://github.com/rubygems/rubygems/commit/3b058e5eca
|
|
## What was the end-user or developer problem that led to this PR?
The old URL https://github.com/testdouble/standard is mentioned.
## What is your fix for the problem, implemented in this PR?
This PR updates to the new URL https://github.com/standardrb/standard.
https://github.com/rubygems/rubygems/commit/eeafba72fc
|
|
https://github.com/rubygems/rubygems/commit/085d2776d8
|
|
Pick from https://github.com/rubygems/rubygems/commit/e9304aed7e43308b99e70c2f7b92028315fee8a5
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
Prior to this commit `bundle binstubs --standalone --all` would output a
warning about not being able to generate a standalone binstub for
bundler.
This warning predates the `--all` option, and I don't think it makes
sense in this context. The warning makes good sense when explicitly
trying to generate a bundler standalone binstub with `bundle binstubs
bundler --standalone`, since that command won't do what the user might
have expected. But `--all` is not specifically asking for bundler, and
having it report each time that the bundler binstubs could not be
generated does not seem particularly helpful. The only way to make that
warning go away would be to stop using `--standalone --all`.
This commit skips the warning when running with the `--all` option.
https://github.com/rubygems/rubygems/commit/e6a72e19eb
|
|
without a value
https://github.com/rubygems/rubygems/commit/c242311158
|
|
https://github.com/rubygems/rubygems/commit/3bf8e59304
|