Tap providing older versions of tool for macOS versions incompatible with latest; conflicts_with behavior questions.

[rgoldberg]

I am overhauling the mas custom tap to install older versions of mas on macOS versions that do not support the current version of mas.

1. Is there any easy way for a single mas formula in the tap to install different versions of mas depending one which macOS version is running? I haven't found such a mechanism.
2. If one doesn't exist, I assume it's easiest to create a versioned formula for each mas major version; users can choose the correct versioned formula for their macOS version, as specified in a table in the tap README. The mas tap would have an unversioned mas alias to the current versioned mas formula (currently mas@7).
   1. Assuming that is the correct setup, I think it's probably easier to use conflicts_with all other mas formulae (instead of using keg_only :versioned_formula) in each versioned mas formula because only one mas version should be installed at a time, and conflicts_with simplifies linking. Is that correct?
   2. If so, are conflicts_with checks performed bidirectionally? i.e., besides seeing if any conflicts listed in the newly installing formula are already installed, does brew iterate through all installed formulae to see if any of them indicate that they conflict with the newly installing formula?
   3. I want all the tap formulae to conflict with homebrew/core/mas. Can a formula in the conflicts_with list include its tap as a prefix? If I include mas in the conflicts_with list, does that reference the tap alias, the core formula, both, or neither? If not solely the tap alias, can I reference that solely via mas-cli/tap/mas?
   4. Is there any way to conflict with all other versions of the same formula? Like conflicts_with "mas@*", …? Right now, I'm using conflicts_with "homebrew/core/mas", *(1..6).map { "mas@#{_1}" }, … for mas@7; I replace 6 with V-1 for each mas version V, obviously cleaning it up for V=1 & V=2.
3. Are there any better ways to accomplish any of my goals (high or low level)?

Thanks.

[botantony]

Version resolution depending on system version is inconvenient in formulae (I think it's possible with on_{system} blocks but I don't think it works well with bottles), you can try to use casks for this (examples like calibre might be what you're looking for)

[rgoldberg]

Thanks. I'll investigate a cask.

Do users prefer versioned formulae with bottles over binaries from a single multi-version cask?

The cask is obviously simpler, but would users want to be able to build from source (mainly for trustworthiness)?

I assume that tap bottles should be considered at most as trustworthy as tap casks, because the latter will install from pkgs from mas-cli/mas GitHub Releases.

Given that the vast majority of mas users install via the Core formula, it's probably better to go with the simpler cask.

EDIT: Is there any way to facilitate migrating mas already installed from the tap mas formula to the new tap mas cask? Or will things break for such users unless I name the cask something else?

Thanks again.

[carlocab]

You can also try using depends_on.

depends_on macos: :sequoia

says that the formula can only be installed on Sequoia or newer.

depends_on maximum_macos: :tahoe

says that it can only be installed on Tahoe or older.

You can, obviously, use both to specify a range where the formula can be installed.

You can then declare all but the newest version as keg_only. Or use conflicts_with, but it sounds like you'll end up with many such declarations across multiple formulae.

[rgoldberg]

Thanks for the info.

If I use depends_on macos: & depends_on maximum_macos:, could I have just one versioned mas formula for each macOS range, so there wouldn't be any overlap, so I could avoid keg_only, and just use conflicts_with for the Core formula?

I'd imagine that, if someone's macOS is so old that they cannot install mas from Homebrew Core (which will always support the 3 macOS major versions supported by Apple & by Homebrew tier 1), then they're unlikely to ever update to a newer macOS, so I shouldn't need to worry much about mas@1, mas@4, or mas conflicting with each other (I'd use an unversioned mas formula for the current version; whenever a new major version removes support for any macOS versions, I'd create a new versioned formula for the then newly penultimate mas major version).

I'll still probably go for a cask, unless anyone raises any objections, because user could get the correct mas per macOS without choosing any versioned formula, and I could also remove my modified bottle building code, simplifying release & dimpligyinhg keeping tap workflows up-to-date with what's provided from Homebrew.

Thanks.

[bevanjkay]

If you're not worried about the files passing the inbuilt brew style, you can be a bit more flexible with the branching than what is allowed in homebrew-cask. Here's an example of a third-party tap that has a formula with more traditional if branches; https://github.com/oven-sh/homebrew-bun/blob/main/Formula/bun.rb

Note that very shortly the minimum macOS required to run Homebrew itself will be big_sur, so anything older won't work regardless of how the tap handles things.