Deprecate homebrew-cask-versions and migrate casks to homebrew-cask

[gdams]

Provide a detailed description of the proposed feature

Now that we have enough automation in place, I propose that we deprecate homebrew-cask-versions and either migrate or deprecate (on a case-by-case basis) the casks that are listed there.

CC @MikeMcQuaid @vitorgalvao

What is the motivation for the feature?

From a maintainers point of view, maintaining two repos is more work than just one. There are only a small number of casks listed at homebrew-cask-versions and by migrating them to this repo we improve the end-user experience (by not needing to tap cask-versions).

Example use case

n/a

[bevanjkay]

I am generally in favour of doing this. We will need a way of handling the different versions (ie. beta, nightly, etc..) in the main cask repo. In the cases of legacy major versioned casks, we will need a syntax there as well. Not sure on the pros and cons of the @#{version} syntax from homebrew-core.

It is probably worth discussing merging homebrew-cask-drivers at the same time. I am not aware of any downsides of moving them into the main cask repo, other than there being a number of unpopular (niche) driver casks. Perhaps moving casks with a certain analytic figure could be the way to go?

[MikeMcQuaid]

Not sure on the pros and cons of the @#{version} syntax from homebrew-core.

I think it'd be good to be consistent unless it's overly laborious in terms of code changes required.

[MikeMcQuaid]

It is probably worth discussing merging homebrew-cask-drivers at the same time. I am not aware of any downsides of moving them into the main cask repo, other than there being a number of unpopular (niche) driver casks. Perhaps moving casks with a certain analytic figure could be the way to go?

Agreed. I'd love to see us get down to ideally a single homebrew-cask repo and have the others either archived or migrated out.

[gdams]

In the cases of legacy major versioned casks, we will need a syntax there as well. Not sure on the pros and cons of the @#{version} syntax from homebrew-core.

Looking at most of the casks in cask-versions they either have a major version number (e.g cask9.rb) or use cask-beta, cask-nightly cask-pre, cask-edge, cask-legacy, cask-dev.

It would be good to agree on a standard for beta builds.

With legacy builds I feel the simplest way is to use the semver major approach (e.g temurin8 or temurin11)

I would suggest that we begin by migrating all of the versioned casks (as they seem to be the simplest to carry over and then look back round for the remaining casks?

[bevanjkay]

Looking at most of the casks in cask-versions they either have a major version number (e.g cask9.rb) or use cask-beta, cask-nightly cask-pre, cask-edge, cask-legacy, cask-dev.

It would be good to agree on a standard for beta builds.

I agree that standardised naming conventions are the best option. We will need to consider instances (there's only a couple) that have multiple variants available, google-chrome-dev, google-chrome-canary and google-chrome-beta for example.

With legacy builds I feel the simplest way is to use the semver major approach (e.g temurin8 or temurin11)

This is currently how the casks are named, however it isn't consistent with homebrew-core.

[gdams]

This is currently how the casks are named, however it isn't consistent with homebrew-core.

So let's say we decided to rename the versioned ones to (e.g temurin@11) to match homebrew-core. Would we be able to use the tap_migrations.json to redirect users? I'm not sure how that works and whether it supports cask name changes or just migrations to homebrew-core?

[MikeMcQuaid]

I'm not sure what the cask support is like for renaming. It was implemented for formulae but not sure if it ever was for casks.

[gdams]

I'm not sure what the cask support is like for renaming. It was implemented for formulae but not sure if it ever was for casks.

Yeah it looks like we'd need to add support for Aliases to homebrew-cask (which wouldn't be a bad thing to do TBF)

[bevanjkay]

@gdams Renaming is not currently supported for cask - so would be a blocking requirement. But has been definitely needed - see #111512 and the zoom/zoomus rename.

[MikeMcQuaid]

I'd rather see these merged before we block on renaming. With that in mind: I think we should just keep the existing names.

[gdams]

I'd rather see these merged before we block on renaming. With that in mind: I think we should just keep the existing names.

I can take a look at adding support for Aliases? I've never looked at the actual CLI codebase in my life but this would make the migration 100 times easier (and cleaner)

[MikeMcQuaid]

@gdams you're welcome to take a look. I'd suggest instead of aliases that you look at https://github.com/Homebrew/homebrew-core/blob/master/formula_renames.json and the relevant code that handles it (brew migrate, Migrator) to consider allowing it to support casks, too.

[MikeMcQuaid]

(note: renames add implicit aliases)

[vitorgalvao]

I can take a look at adding support for Aliases?

Instead of aliases, we should get the equivalent to formula_renames.json for casks. That’s a much needed feature.

It would be good to agree on a standard for beta builds.

The (current) standard is what upstream calls it because it’s simple and allows the same software with multiple variants.

Regarding homebrew-cask-drivers, we should not just move the casks because it would create a mess—most aren’t popular and the naming scheme for that repo is different (it includes the vendor as a prefix). We should instead just move the really popular ones which have an app (i.e. not simply a kext or similar) and let the others go, ideally giving away the repo to someone in the community who feels like taking care of it.

[gdams]

@MikeMcQuaid / @vitorgalvao are either of you able to point me in the rough direction where such a code change might be made? I'm trying to locate where the existing formula_renames.json stuff is actually used

[MikeMcQuaid]

Instead of aliases, we should get the equivalent to formula_renames.json for casks. That’s a much needed feature.

👍🏻 and it brings aliases for free

We should instead just move the really popular ones which have an app (i.e. not simply a kext or similar) and let the others go, ideally giving away the repo to someone in the community who feels like taking care of it.

👍🏻

@MikeMcQuaid / @vitorgalvao are either of you able to point me in the rough direction where such a code change might be made? I'm trying to locate where the existing formula_renames.json stuff is actually used

@gdams best bet is to ask in Slack, I'm snowed under personally.

[github-actions]

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

[github-actions]

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

[JounQin]

In homebrew-cask-versions, there are some casks not using official download links due to unstable appcenter links like clashx-pro, will that be allowed when merging?

I have a proposal #107354 before to add a new AppCenterDownloadStrategy, but I personally not very familiar with ruby and testing with it.

Should these cases be considered?

[MikeMcQuaid]

@JounQin Can you elaborate what is meant by "unstable" here? Thanks!

[michaelblyons]

Someone might want to change the documentation at https://docs.brew.sh/Acceptable-Casks#beta-unstable-development-nightly-or-legacy

[p-linnane]

It will be updated once the migration is complete.

[p-linnane]

Closing as this is now complete.

[MikeMcQuaid]

Great work here everyone!

What do we want to do with homebrew-cask-fonts?

[miccal]

What do we want to do with homebrew-cask-fonts?

Move them all into a sharded directory called font and let https://github.com/Homebrew/homebrew-linux-fonts know to pull updates from that folder only?

[p-linnane]

Fully agree with @miccal. It would be nice to get rid of the fonts repo and have everything in the main (only) repo.

[bevanjkay]

Yeah I think that seems reasonable, unless adding 2,200 files to a directory is going to cause issues. Note that many are "Google Fonts" which are seldom updated, as they are unversioned and are managed systematically.

[p-linnane]

Yeah I think that seems reasonable, unless adding 2,200 files to a directory is going to cause issues. Note that many are "Google Fonts" which are seldom updated, as they are unversioned and are managed systematically.

I figured we would create a fonts directory and shard it.

[razvanazamfirei]

Yeah I think that seems reasonable, unless adding 2,200 files to a directory is going to cause issues

If we do this, I'd like to change the syntax check to be scoped to modified files only. Tap syntax checks are already taking too long.

[MikeMcQuaid]

Yeah I think that seems reasonable, unless adding 2,200 files to a directory is going to cause issues.

It is. They will need to be sharded further inside that directory.

Also they'll need to be renamed to start with font- (if they aren't already) and move the existing font* casks in there, too, otherwise various bits of tooling/libraries will break down.

If we do this, I'd like to change the syntax check to be scoped to modified files only.

We should not do this. I know it's frustrating for this to take a while but this sort of modification detection ends up inevitably failing and ending up with a broken master.

If they are taking too long: let's figure out how best to speed up these checks.

Move them all into a sharded directory called font and let Homebrew/homebrew-linux-fonts know to pull updates from that folder only?

I don't think it's worth optimising too hard based on this tap.

[bevanjkay]

Yeah they all have tokens that start with font-*. But they aren't currently sharded further, so will need to include that in the migration.

[MikeMcQuaid]

Yeah they all have tokens that start with font-*. But they aren't currently sharded further, so will need to include that in the migration.

Yup. This should probably be handed a bit like lib in homebrew-core:

• there should be both f and font (or font-) subdirectories
  unlike homebrew-core:
• the font/font- subdirectory should probably also be sharded

This will likely require work in Homebrew/brew; I don't think there's currently supported for another level of directories.

Another option would be to shard by f, font-a, font-b, etc. in the Casks root. This would (except for brew create) require no/fewer Homebrew/brew changes.

[vitorgalvao]

Don’t forget there is (was?) a bot which kept the Google Fonts up to date automatically. However small the change to the structure, that will need an update to the new locations.

[MikeMcQuaid]

Don’t forget there is (was?) a bot which kept the Google Fonts up to date automatically. However small the change to the structure, that will need an update to the new locations.

How does this differ from other autobump/livecheck workflows? Ideally it should be part of the same thing.

[vitorgalvao]

Yes, I don’t mean it in the sense that it will be a problem, I mean it in the sense “whoever works on the transition, don’t forget this important part which may not be immediately obvious”.

[MikeMcQuaid]

@vitorgalvao All good, thanks!

[bevanjkay]

There's currently two automations that are managing casks in the homebrew-cask-fonts repository. One is inside of the repo, and one is external that updates the "nerd fonts" supplied from the ryanoasis repository (example PR: Homebrew/homebrew-cask-fonts#9236). It's worth noting that the "nerd fonts" specifically are relatively popular with three in the top-100 casks (last 30d install).

The Google Fonts automation is currently setup as a python script that on a schedule checks the https://github.com/google/fonts repository and adds/removes fonts, as well as updates any that have had changes.

Both of these do a little bit more than our current tooling for autobump/livecheck, because they also check and update if there have been changes that need to be reflected as font artifacts. I don't think this is something that could be rolled out wider, because many font-* casks require user-intervention to select the most "correct" artifacts within the archives.

[MikeMcQuaid]

one is external that updates the "nerd fonts" supplied from the ryanoasis repository (example PR: Homebrew/homebrew-cask-fonts#9236). It's worth noting that the "nerd fonts" specifically are relatively popular with three in the top-100 casks (last 30d install).

I think it's worth opening an issue for them letting them know about our plans to change things and then tell them when things are moved over.

The Google Fonts automation is currently setup as a python script that on a schedule checks the google/fonts repository and adds/removes fonts, as well as updates any that have had changes.

I think this would be a good chance to move this from Python to Ruby.

because many font-* casks require user-intervention to select the most "correct" artifacts within the archives.

Thanks for context 👍🏻

---

Reopening this but anyone feel free to close and move to a new issue instead.