Next steps for `HOMEBREW_INSTALL_FROM_API`

[Rylan12]

Provide a detailed description of the proposed feature

Here are the tasks that need to be completed in order to consider HOMEBREW_INSTALL_FROM_API ready for official testing by maintainers and interested users:

• [x] https://github.com/Homebrew/brew/pull/13795: brew update should still update core and cask taps when HOMEBREW_INSTALL_FROM_API and HOMEBREW_DEVELOPER are both set (allowing maintainers to test this and still maintain homebrew/core and homebrew/cask)
• [x] https://github.com/Homebrew/brew/pull/13815: Allow HOMEBREW_DEVELOPER users to use all dev commands even with HOMEBREW_INSTALL_FROM_API set
• [ ] Migrate all casks to use on_{macos_version} blocks instead of if MacOS.version conditionals
• [ ] Remove the small number of Hardware::CPU methods that slipped through in formulae and casks (and improve the rubocops to catch more cases)
• [ ] Update CaskLoader to load casks from their JSON API like we do with formulae
• [ ] A warning or some sort of message should be shown when installing a formula with a post_install block or a cask with a {pre,post}flight block so that users know that some things may not work at the moment (or, in the case of formulae, they need to run brew postinstall <formula>)
• [ ] https://github.com/Homebrew/brew/pull/13842: I think it might be a good idea to mark in the INSTALL_RECEIPT.json or .metadata directory whether the formula/cask was installed from the API in case we run into issues and it's helpful to know how a formula was installed. But, this is a lower priority and might not even be needed at all
• [ ] We need to handle download errors of the formula.json and cask.json files

What is the motivation for the feature?

I'm back at school so my availability over the next several months will be much more limited and less consistent. I'm opening this tracking issue to help monitor progress over time.

How will the feature be relevant to at least 90% of Homebrew users?

Eventually, HOMEBREW_INSTALL_FROM_API will be the default for everyone.

What alternatives to the feature have been considered?

None

[MikeMcQuaid]

[ ] A warning or some sort of message should be shown when installing a formula with a post_install block or a cask with a {pre,post}flight block so that users know that some things may not work at the moment (or, in the case of formulae, they need to run brew postinstall <formula>)

Is this something we expect to be fixed but just hasn't been yet? For a bottle installation, it should be able to use the post_install from within the bottle, right?

• I think it might be a good idea to mark in the INSTALL_RECEIPT.json or .metadata directory whether the formula/cask was installed from the API in case we run into issues and it's helpful to know how a formula was installed. But, this is a lower priority and might not even be needed at all

This is a good idea 👍🏻

I'm back at school so my availability over the next several months will be much more limited and less consistent. I'm opening this tracking issue to help monitor progress over time.

No worries, thanks for opening this tracking issue!

[Rylan12]

Is this something we expect to be fixed but just hasn't been yet? For a bottle installation, it should be able to use the post_install from within the bottle, right?

This requires us to build new bottles every time the postinstall method changes. And it's hard to tell whether existing bottles have outdated postinstall methods, so this might require rebottling everything. Also, style changes in the future may require rebottling all formulae that have postinstall blocks (currently 239 formulae) for the same reason. There's been some discussion in various places about the pros and cons of this as well as some other potential ways to deal with this, but I'll have to track those down

[MikeMcQuaid]

This requires us to build new bottles every time the postinstall method changes.

Yeh, I think this is fine for changes we need to push to users. Don't think this needs a warning as long as maintainers are made aware with docs/Slack communication.

And it's hard to tell whether existing bottles have outdated postinstall methods, so this might require rebottling everything.

This seems overkill.

Also, style changes in the future may require rebottling all formulae that have postinstall blocks (currently 239 formulae) for the same reason.

Why would a style change need rebottling?

but I'll have to track those down

That'd be great, thanks ❤️!

[Rylan12]

Why would a style change need rebottling?

I used the wrong words here. Most style changes that are truly only style changes should be fine as long as the old style isn't invalid ruby or anything like that. Really the issue is deprecations and stuff that, if not updated, might not be able to be understood by a brew version newer than the one that created the bottle.

but I'll have to track those down

We discussed this a bit on June 18 in Slack. I'll send a link over in slack to the messages. Here on GitHub, we discussed this in https://github.com/Homebrew/brew/pull/12350, but there probably isn't anything in that discussion that didn't make it into the slack one.

[MikeMcQuaid]

Really the issue is deprecations and stuff that, if not updated, might not be able to be understood by a brew version newer than the one that created the bottle.

Gotcha 👍🏻

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[hyuraku]

@Rylan12

Migrate all casks to use on_{macos_version} blocks instead of if MacOS.version conditionals

I guess we need a new issue on https://github.com/Homebrew/homebrew-cask to get the word out to people and have them modify the casks. How about it?

[p-linnane]

@hyuraku I am game to start working on these.

[Rylan12]

@hyuraku and @p-linnane, thanks for taking the initiative on this!

I think an issue in homebrew/cask would be great, but only once we've started the process and made sure all of its kinks are worked out (clearly from the past few days, we're not quite there yet 😅)

---

The immediate next steps that I think we need to take to get this ready are:

• Make brew readall simulate every OS/arch combination
• Fix homebrew/cask CI to not rely on checking the cask's contents for if MacOS.version conditionals

I plan on working on both of these soon, but if anyone else is interested feel free to give it a go

[hyuraku]

I think an issue in homebrew/cask would be great, but only once we've started the process and made sure all of its kinks are worked out (clearly from the past few days, we're not quite there yet 😅)

Understood, I will try to solve the other task.

[hyuraku]

@Rylan12 I have a question about We need to handle download errors of the formula.json and cask.json files I couldn't find the code where we download cask.json; should we add the code to download cask.json by any chance?

[Rylan12]

We will once all casks are migrated to use on_monterey and friends. Only then (and maybe after some more fixes) will we be able to load casks from the JSON API. Right now, the existing cask API doesn't contain enough information to do so.