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>
- Since comment detection is only used in `Stanza`, move it there.
- The `stanzaify` method was only in `CaskBlock` since the other use of
`Stanza.new` was. Since it's only used in one other place, move it to
where it's used.
- 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.
