Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gdams opened this issue Oct 5, 2021 · 50 comments
Closed

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

gdams opened this issue Oct 5, 2021 · 50 comments
Labels

Comments

@gdams
Copy link
Contributor

gdams commented Oct 5, 2021

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

@gdams gdams self-assigned this Oct 5, 2021
@gdams gdams added the awaiting maintainer feedback Issue needs response from a maintainer. label Oct 5, 2021
@bevanjkay
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

gdams commented Oct 5, 2021

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
Copy link
Member

bevanjkay commented Oct 5, 2021

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
Copy link
Contributor Author

gdams commented Oct 5, 2021

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
Copy link
Member

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
Copy link
Contributor Author

gdams commented Oct 5, 2021

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Contributor Author

gdams commented Oct 5, 2021

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
Copy link
Member

@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
Copy link
Member

(note: renames add implicit aliases)

@vitorgalvao
Copy link
Member

vitorgalvao commented Oct 5, 2021

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
Copy link
Contributor Author

gdams commented Oct 5, 2021

@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
Copy link
Member

MikeMcQuaid commented Oct 5, 2021

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
Copy link

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 github-actions bot added the stale Issue which has not received any feedback for some time. label Oct 27, 2021
@gdams gdams removed the stale Issue which has not received any feedback for some time. label Oct 27, 2021
@dr3mro

This comment has been minimized.

@neutric

This comment has been minimized.

@github-actions
Copy link

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 github-actions bot added the stale Issue which has not received any feedback for some time. label Nov 22, 2021
@JounQin
Copy link
Contributor

JounQin commented Nov 22, 2021

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?

@github-actions github-actions bot removed the stale Issue which has not received any feedback for some time. label Nov 22, 2021
@MikeMcQuaid
Copy link
Member

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

@miccal miccal unassigned gdams Apr 2, 2024
machupicchubeta added a commit to machupicchubeta/dotfiles that referenced this issue Apr 28, 2024
```
$ brew info --cask google-chrome-canary

Warning: Cask homebrew/cask-versions/google-chrome-canary was renamed to google-chrome@canary.
==> google-chrome-canary: latest
https://www.google.com/chrome/canary/
Installed
/opt/homebrew/Caskroom/google-chrome-canary/latest (61.4KB)
==> Name
Google Chrome Canary
==> Description
Web browser
==> Artifacts
Google Chrome Canary.app (App)
```

Refs.
- Homebrew/homebrew-cask-versions#20186
- Homebrew/homebrew-cask#172349
- Homebrew/homebrew-cask#112102
@michaelblyons
Copy link

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

@p-linnane
Copy link
Member

It will be updated once the migration is complete.

@p-linnane p-linnane removed awaiting maintainer feedback Issue needs response from a maintainer. in progress labels May 3, 2024
@p-linnane
Copy link
Member

Closing as this is now complete.

@MikeMcQuaid
Copy link
Member

Great work here everyone!

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

@miccal
Copy link
Member

miccal commented May 3, 2024

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
Copy link
Member

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

@bevanjkay
Copy link
Member

bevanjkay commented May 3, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

@vitorgalvao All good, thanks!

@bevanjkay
Copy link
Member

bevanjkay commented May 6, 2024

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
Copy link
Member

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.

@MikeMcQuaid MikeMcQuaid reopened this May 7, 2024
@miccal miccal closed this as not planned Won't fix, can't repro, duplicate, stale May 26, 2024
@miccal miccal closed this as completed May 26, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

14 participants