This was originally used by the API but was replaced months
ago by SimulateSystem. Essentially, it's only current use
was in the #to_h method but is not used internally at all
when creating cask instances from the API JSON.
- This test tests nothing. And the TODO comment is wrong.
- We _could_ fix it, but it's a very edgy edge case which pertains to
`livecheck` blocks which currently don't have stanza grouping or
ordering cop support. If we decide in the future to add these, we can
add this back too (provided I remember).
- Also I think I may have got confused with the stanza grouping vs.
stanza ordering cops when writing this, rendering this test more
useless.
- Since moving `comments_hash` to `Stanza`, we've been using the wrong
kind of "comments": the comments for the _stanza_, not the comments
for the entire Cask.
- Add a test to ensure this actually works. There was previously an
infinite loop here due to the bad `comments`, visible in a `StanzaOrder`
cop test, which I speculatively added a failing test for. Turns out
that supporting nested stanza _ordering_ (vs. just grouping) is a
whole separate piece of work (there are multiple TODOs there already),
so I've backed that out and will do that separately.
Following #14998, reorder the locale segments to `language`, `script`,
`region` to match the standard format. This does not require changes
outside the `Locale` class because `Locale` instances are always
constructed with the `parse` method.
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
As I mentioned in #15146, two `Cask::DSL` tests failed on my local
machine, even on `master`. `git bisect` suggested that it was #14998
that introduced those failures. It turned out that the tests here could
fail under certain locale settings, like this one below:
$ defaults read -g AppleLanguages
(
"en-GB",
"zh-Hans-SG"
)
This is not actually a regression. With the aforementioned locale
settings, an explicit `let(:languages) { ["en"] }` setting would result
in locales being considered in the following order: `en`, `en-GB`,
`zh-Hans-SG`. For each of them, the `detect` method from `Locale` is
called, with `locale_groups` as `[["zh"], ["en-US"]]`, the list of
locales defined in the test cask.
def detect(locale_groups)
locale_groups.find { |locales| locales.any? { |locale| eql?(locale) } } ||
locale_groups.find { |locales| locales.any? { |locale| include?(locale) } }
end
Neither of `en` and `en-GB` satisfies the `detect` conditions. (Note
that `Locale.parse("en").include?("en-US")` evaluates to `false`.) But
`zh-Hans-SG` does (because `Locale.parse("zh-Hans-SG").include?("zh")`
is `true`). So, despite having `:languages` set to `en`, the Chinese
locale was still used.
This could be fixed by generalising the test cask's English locale
settings from `en-US` to `en`. This is already the case for most
existing casks:
$ grep 'language "en.*", default: true' Casks/*.rb
Casks/battle-net.rb: language "en", default: true do
Casks/cave-story.rb: language "en", default: true do
Casks/firefox.rb: language "en", default: true do
Casks/libreoffice-language-pack.rb: language "en-GB", default: true do
Casks/libreoffice-language-pack.rb: language "en-GB", default: true do
Casks/openoffice.rb: language "en", default: true do
Casks/seamonkey.rb: language "en-US", default: true do
Casks/thunderbird.rb: language "en", default: true do
Casks/wondershare-edrawmax.rb: language "en", default: true do
Note that this should make the language stanza tests independent of
locale settings, because `zh` and `en` should be able to capture all the
test cases.
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
- A variant of this was an ancient TODO from 2018 (with `if/else` blocks).
- Now in 2023 we have `on_*` blocks within Casks that are very common.
- The most common stanzas present inside `on_*` blocks are `version`,
`sha256` and `url`. So I feel like it's worth keeping a consistent
style for these inside and outside `on_*` blocks.
- Cask source paths were added to the API in 844db75361. The main
`everything.json` file was updated with the new data in that commit,
but this one was missed causing local test failures.
Before:
```
Cask::Cask#to_h when loaded from cask file returns expected hash
Failure/Error: expect(JSON.pretty_generate(hash)).to eq(expected_json_after_ventura)
[...]
Diff:
@@ -93,7 +93,7 @@
"en",
"eo"
],
- "ruby_source_path": "Formula/everything.rb",
+ "ruby_source_path": "Casks/everything.rb",
"ruby_source_checksum": {
"sha256": "b2707d1952f02c3fa566b7ad2a707a847a959d36f51d3dee642dbe5deec12f27"
}
# ./test/cask/cask_spec.rb:231:in `block (4 levels) in <top (required)>'
# ./test/support/helper/spec/shared_context/homebrew_cask.rb:52:in `block (2 levels) in <top (required)>'
```
- Fixing the test expected output was unbelievably tedious.
- There's been debate about this setting being `false` but in
https://github.com/Homebrew/brew/pull/15136#issuecomment-1500063225
we decided that it was worth using the default since RuboCop behaviour changed
so we'd have had to do some horrible things to keep it as `false` -
https://github.com/Homebrew/brew/pull/15136#issuecomment-1500037278 -
and multiple maintainers specify the `--display-cop-names` option to
`brew style` themselves since it's clearer what's gone wrong.
The preferred method is opt_bin because that works
with the API and is more portable (works between versions).
Also removed the last example from the docs of `bin/"name"`
from the service block section
