Fix casks with depends_on that reference pre-Yosemite

[vitorgalvao]

If you get an error of the type Error: Cask 'hex-fiend-beta' definition is invalid: invalid 'depends_on macos' value: ":lion", where hex-fiend-beta can be any cask name, and :lion any macOS release name, run the following command:

/usr/bin/find "$(brew --prefix)/Caskroom/"*'/.metadata' -type f -name '*.rb' -print0 | /usr/bin/xargs -0 /usr/bin/perl -i -pe 's/depends_on macos: \[.*?\]//gsm;s/depends_on macos: .*//g'

This will remove all depends_on macos references of installed casks (where it doesn’t matter anymore anyway).

We should deal with these cases better in the future.

[glhrmv]

I was trying to uninstall the keka cask and I couldn't because of this error message. Thank you.

[ran-dall]

@vitorgalvao I remember that we had a conversation with @core-code about trying 'us' trying to support as many releases of macOS as possible. I now see what you were saying about the high maintenance overhead...

Maybe we should have it a harder requirement of only supporting the last two releases of macOS. I know it doesn't fix the issue, but it would mitigate it a bit by not having as many tags. 🏷

We should consider that we're talking ~31% of users; which are on something different from the last two releases of macOS.

[vitorgalvao]

@Rand-all This specific lack of support for pre-Maverick is now enforced in the core, with the release of Homebrew 2.0.0 (today!).

[ran-dall]

@vitorgalvao Yea I saw about an hour after I wrote that...haha! 👍 So should we start to delete the support off casks?

[reitermarkus]

I think we can safely remove depends_on: '>= :mavericks'.

[ran-dall]

@reitermarkus 🧞‍♂️It shall be done, then...

[brianbrownton]

#58460

[brianbrownton]

#58507

[felker]

By the way, if you have edited your PATH environment variable so that GNU sed is the default, @vitorgalvao's command won't work as written:

sed: can't read /depends_on macos:/d: No such file or directory

Be sure to use BSD sed, e.g.:

/usr/bin/find "$(brew --prefix)/Caskroom/"*'/.metadata' -type f -name '*.rb' -print0 | /usr/bin/xargs -0 /usr/bin/sed -i '' '/depends_on macos:/d'

[vitorgalvao]

Thank you @felker. Added /usr/bin/ to the other tools as well, just in case.

[brianbrownton]

Is there something that can be done from the HBC side to prevent folks having to deal with this?

[vitorgalvao]

Is there something that can be done from the HBC side to prevent folks having to deal with this?

Old casks (i.e. the ones in .metadata) are the cause of issues like this. We can:

1. Fallback to the current cask when the stored one gives an error.
2. Instead of storing the cask at the moment of install, generate a bash file with the uninstall commands.

There’s an issue I’m not finding where we spitballed more ideas. It’s not #49716, though that one also has some of them.

[brianbrownton]

If I sub a PR to brew that would check if the metadata file exists and update it to work with the current release without causing issues, is that something that would be desired?

[vitorgalvao]

check if the metadata file exists and update it to work with the current release

The problem isn’t metadata files not existing; it’s that they exist but are old (i.e. use deprecated features). Replacing them with the current release outright would defeat the purpose — we want those old instructions, which is why we keep the files.

I see option 2 as more desirable, because that would decouple the uninstall (and zap) instructions from cask functionality, meaning they’ll be resilient to DSL changes.

Even so, before making a PR it would be desirable to open an issue to discuss the exact solution.

[brianbrownton]

My proposal is basically just to run the sed pipe you provided on the metadata file (for installed casks only, yea?) on brew update so that people don't have to run it manually. I was only interested in doing it if it was a quick fix, I don't really want to open an issue and get into a big thing about how to fix this... I guess I'm not THAT altruistic ;)

[vitorgalvao]

@brianmorton Ah, yes, my suggestion was about fixing it for every future case. I don’t think a fix for this particular one is necessary. The issue seems to be doing its job — people are finding it OK and not opening too many issues about it.

[mxr576]

The suggested command breaks Onyx, because it defines dependencies in an array.

Error: Cask 'onyx' is unreadable: /usr/local/Caskroom/onyx/.metadata/3.5.6/20190115061551.579/Casks/onyx.rb:30: syntax error, unexpected ',', expecting keyword_end

[haykam821]

When I opened #57996, the old versions were referenced incorrectly (mountain_lion instead of :mountain_lion). As such, a simple find/replace for :mountain_lion or other old versions didn't work. Perhaps we should have a script that checks if a cask's version references are outside of symbolic names or version strings.

[vitorgalvao]

Perhaps we should have a script that checks if a cask's version references are outside of symbolic names or version strings.

No need for a script, that should be part of audit, as it was invalid code.

[vitorgalvao]

@zubrakadzo Run the line in the top post.

[vitorgalvao]

Updated the top one-liner to cover multi-lines cases enclosed by []. If you find any other cases that fail, please let me know.

[vitorgalvao]

@cypher004 The solution is in the top post. Please read before posting.

There haven’t been any meaningful comments in this issue for a while, so I’ll lock it.