[Suggestion] new install/update mechanism

[xu-cheng]

I recommend a new install/update mechanism for this project. Homebrew now allows the external commands living in the cmd folder in the taps. So instead of installing by Formula, we can install and update homebrew-cask by this:

• Install: brew tap caskroom/homebrew-cask
• Update: brew update

This simplifies the user experience, reduces the redundant files in the system and makes update much easier (brew upgrade brew-cask is no longer needed). However, it requires users to uninstall the old version homebrew-cask to avoid the conflict. You can find more information on homebrew-livecheck who has switched to this new mechanism.

[rolandwalker]

Hi! Thanks!

Yes, we are aware of the new mechanism but it might need more discussion among @caskroom/maintainers .

Pros

• simplified user experience
• maybe fewer issues (more concise update command #4981) caused by Homebrew keeping around three or more copies of homebrew-cask (comment)

Cons

• we would need to maintain a development branch in git, and be disciplined about that, because backend code in master goes out to users immediately
• migrating might require user action (comment)

Further study

One thing that needs further research (to determine whether it is a pro or a con) is: one reason why we recommend the ridiculous, long, confusing command

$ brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup

even though we don't particularly like it (#4981) is that the full command often solves specific user issues.

Those issues appear to be caused by Homebrew accidentally keeping around old copies of our software.

If the new mechanism makes that less likely to happen, that is a strong "pro". If the new mechanism allows multiple copies to hang around, but makes it harder to clean them out by an explicit command, that is a strong "con".

(claui: Updated this list with points gathered from the comments)

[xu-cheng]

If the new mechanism makes that less likely to happen, that is a strong "pro".

That's exactly what happens. Using new mechanism, there will be only one copy which it's in /usr/local/Library/Taps/.... (of course, it requires the old version cask being uninstalled.) While the old way keeps three copies: one in Cache, one in Tap and one in Cellar.

[xu-cheng]

Correction, the old way keeps more than three copies: one in Cache, one in Tap and maybe more than one in Cellar.

[claui]

@xu-cheng Love the idea! I’m always biased towards UX so I’m inclined to second that. ☺️

Still, some random thoughts (as always, over-the-top with verbosity – sorry guys):

1. I very much agree to the points @rolandwalker makes, especially the point on the development branch. That said, don’t we have to be already very disciplined as of today?
   I remember that when I was fairly new to homebrew-cask and GitHub, brew updateing used to make me feel uneasy. Questions were coming to mind like: can I trust the update process? Is anyone really allowed to update Casks? What happens if someone decides to sneak in something malicious? Maybe piggybacking on a random updated Cask? Does every DSL block in every Cask being evaled? and so on.
   Of course, trust was gained as I discovered how stuff actually gets reviewed, and how everyone is doing excellent work behind the scenes to keep an eye on things, which I wasn’t aware of back then.
2. What changes would be needed on Homebrew’s end? For example, I’d love not to break this convenience shortcut for installing. @MikeMcQuaid maybe your guts have a say about this?
3. Are there other places where Homebrew also relies on brew-cask being a formula? (I did a quick search but tbh I don’t feel at home yet with the Homebrew backend)
4. Would both projects have to coordinate their releases (that one time)?
5. Do we consider the following silly edge case acceptable?
   User decides to migrate, starts by uninstalling homebrew-cask as told, fails to brew update for some strange reason, then brew taps into the new repo. Would the old formula/command still stick around? What would happen?
6. Assume a user somehow ends up with duplicate external commands like in @xu-cheng’s example. How does brew (external) actually behave when it finds such a conflict? Does it a) report the collision to the user and then fail? Or does it b) silently recover, picking one of the conflicting commands over the other?
7. Assume Homebrew’s behavior were to change from 6a to 6b or vice versa. Would this make migrating easier from a user’s POV? Or rather more confusing?
8. Can we think of a clever way to make homebrew-cask auto-migrate itself, similar to how it did when the repo changed homes?
9. Would you consider it worth the effort if the CLI had a (one-time) brew cask _migrate command to make migrating super easy?

I still pretty much love the idea – just being curious to know the ramifications. Apologies for verbosity … and of course for my limited understanding of how Homebrew works. In some places, I still consider it magic ✨

[MikeMcQuaid]

What changes would be needed on Homebrew’s end? For example, I’d love not to break this convenience shortcut for installing. @MikeMcQuaid maybe your guts have a say about this?

We could remove a couple of lines there. It'd be really easy to do and easy to handle both cases in case they are out-of-sync.

Are there other places where Homebrew also relies on brew-cask being a formula? (I did a quick search but tbh I don’t feel at home yet with the Homebrew backend)

Nope, that's it.

[claui]

@MikeMcQuaid Sounds good, thanks! ☺️

[claui]

I think this answers all of 2., 3., and 4.

[xu-cheng]

After Homebrew/legacy-homebrew#34732 is merged, cmd folders in taps will always take higher priority. So question 5, 6 and 7 should be resolved.

So we only need to ask user to uninstall old version to make system more clean. Or as suggested by question 8 and 9, let brew cask do it automatically.

[rolandwalker]

@claui thanks for raising all the needed points. @xu-cheng knowing that there are some other relevant pending PRs is useful data.

Going back to where we started, this is a new thing, and possibly good for us. But we have a larger userbase than say, homebrew-livecheck, and there are many external scripts which invoke brew cask. We are pre-alpha, and willing to change things, but in order to take good care of our users, we have to change deliberately.

Also, when something goes wrong, GitHub and IRC are flooded with repeats of the same question, and our productivity suffers.

• We should wait a solid month after the feature has stabilized before we research and decide.
• If we do pursue it, we must have a transition plan. Both the tap migration and DSL transitions were major changes that went smoothly overall.
• There are many tricky points, eg much documentation would change, and then users running an old version would see incorrect instructions for updating if they consulted the web.

What it needs is for someone to anticipate all the details, work out the transition, and deploy a series of PRs over a period of a few months.

[vitorgalvao]

We’re in talks of merging the two projects, so this would become irrelevant.