homebrew-cask
homebrew-cask copied to clipboard
Homebrew
Deprecate homebrew-cask-versions and migrate casks to homebrew-cask
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
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?
Not sure on the pros and cons of the
@#{version}syntax fromhomebrew-core.
I think it'd be good to be consistent unless it's overly laborious in terms of code changes required.
It is probably worth discussing merging
homebrew-cask-driversat 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.
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?
Looking at most of the casks in cask-versions they either have a major version number (e.g
cask9.rb) or usecask-beta,cask-nightlycask-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.
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?
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.
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)
@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.
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'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)
@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.
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.
@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
Instead of aliases, we should get the equivalent to
formula_renames.jsonfor 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.jsonstuff is actually used
@gdams best bet is to ask in Slack, I'm snowed under personally.
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[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@dr3mro Please don't litter unrelated issues, opening a new one is still free of charge. ;) Apart from that, Qt-Creator 6 is still in beta stage afaik.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
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?
@JounQin Can you elaborate what is meant by "unstable" here? Thanks!
@MikeMcQuaid Take https://github.com/Homebrew/homebrew-cask/pull/86109/files#diff-3613a5c84fb0ae218d5189a6432b5d06ba33680109ff8fd9fb0f4e7fd11bdc44R6 as example, its download url will be invalid after a few minutes.
@jounqin Yeh, that seems not great. A AppCenterDownloadStrategy sounds like a good fix 👍🏻
In homebrew-cask-versions, there are some casks not using official download links due to unstable appcenter links like
clashx-pro
If a url is in a cask, it’s either official or a mistake. mpv is the one we know about and are discussing how to fix.
If there are more, they need to be corrected; we don’t want non-official links. @miccal You merged this one, do you remember?
None of this precludes an AppCenterDownloadStrategy strategy. A few years ago there was a user who worked for Microsoft and said they’d talk with the team about it, but nothing ever came of it.
If there are more, they need to be corrected; we don’t want non-official links. @miccal You merged this one, do you remember?
Yes I do remember, and I recall being surprised that this one was "stable".
And it still is, it seems:
|-> brew livecheck clashx-pro
clashx-pro : 1.72.0.1 ==> 1.72.0.1
|-> brew fetch clashx-pro
==> Downloading https://appcenter.vercel.app/clashx/clashx-pro/1.72.0.1
==> Downloading from https://appcenter-filemanagement-distrib5ede6f06e.azureedge.net/a59d3822-d12f-417d-8aae-664b2cac83cd/ClashX.dmg?sv=2019-02-02&sr=c&sig=a%2Fojvc3ssxgSHb0mDVyzTKXjLijE0cKo1FgHH9q5EwM%3D&se=2021-11-23T19%3A10%3A40Z&sp=
######################################################################## 100.0%
Downloaded to: /Users/miccal/Library/Caches/Homebrew/downloads/dfd5849e2e33931fef2b41fc63786a6d0bd0b1bf65ae595c3bda0e41cc628b0b--ClashX.dmg
SHA256: 36751e6f18073c1dcd5924b632d7a135123b3a0f6fd6af17040a7fbc4abe0bc3
None of this precludes an
AppCenterDownloadStrategystrategy. A few years ago there was a user who worked for Microsoft and said they’d talk with the team about it, but nothing ever came of it.
I opened an issue with Microsoft at this user's request, but it was never answered and I closed it after a month or two.
IMO the scope here should expand to "migrate casks from all homebrew-cask-* repos into homebrew-cask"
Reminder that moving the drivers repo without a pre-selection could be messy (last paragraph).
The fonts repo is probably worth keeping separate: it has a ton of casks but they are not of interest to everyone and its repo management is mostly automatic.
Is this still open? I have a feeling it should be closed. Can a maintainer check?
https://github.com/homebrew/homebrew-cask-versions has not been archived so it should stay open.