Support for cask equivalents on Linux (eg 1Password GUI & CLI)

[joehorsnell]

Can someone please advise on whether there would be interest in providing support on Linux for formula that on macOS are provided as casks and if so, how? I've searched for similar questions, but can't find anything.

For example, the 1Password GUI on Mac is a cask. Also the CLI is a cask as well, despite not being a GUI app (ie it's installed to /usr/local/bin rather than /Applications.

Both the GUI and CLI are available on Linux, so would it cause any issues to have those as normal formula on Linux?

FWIW I'm a macOS user, but I have colleagues that use Linux and it would be convenient for them to install these apps in the same way.

[carlocab]

The correct solution here might be to try to get Homebrew Cask working on Linux and add this software as Linux casks. That will take some work, however. You're welcome to look into it if you're interested.

[SMillerDev]

If they build from source they can be a formula but I do not think that is the case here. If you want to extend support for casks to Linux I'm sure a lot of people would be very happy with it, but that is going to be a lot of work.

[gromgit]

I think there are two major stumbling blocks with supporting casks on Linux:

1. "When you've seen one Linux...you've seen one Linux." All macOS platforms have a consistent system environment (libraries, services, etc.). The Linux landscape, in contrast, is pretty much "wild west" territory even now. I believe that's why the Linuxbrew core audit complains loudly about linking against any non-Homebrew libraries (except the unavoidable glibc and gcc system libraries).

2. Lack of installers. macOS software vendors provide the necessary installers with their binaries, and/or use standard OS conventions that are easy to specify in a cask. Linux vendors, OTOH, usually provide RPM and/or DEB packages for the most common platforms, and a binary tarball with instructions for everyone else...including "these are the dependencies you have to install, good luck figuring it out". (And then there's the curl | bash method that everyone complains about from a security perspective, but no one's found a better alternative.)

In the end, I suspect any workable Linux cask framework would be some combination of the following:

1. Standard formulae, except pre-built binaries are permitted as starting points.
2. New RPM/DEB strategies that rip the packages apart, while rewriting any embedded paths as best they can.
3. A restricted set of supported distros. "Arch? NO CASKS FOR YOU!"

As @SMillerDev said, it'll be a lot of work, and it probably wouldn't move the needle much beyond the current "formulae-only for Linux".

[joehorsnell]

Thanks for the responses @carlocab, @SMillerDev and @gromgit.

As it happens, for 1Password on Linux, which is actually still a beta release, they provide different instructions for Debian, Red Hat, Arch, etc.

I agree that getting casks to work properly on Linux would be the best approach, but that sounds like a bit of Pandora's box, which given that I don't even use Linux for day-to-day development (macOS for me), I might leave closed. Thanks!

[svallory]

I know this has been marked as answered, but I believe there's a middle that I THINK wouldn't be hard to implement. The idea is to have a mechanism similar to the bottles but with one extra dimension. Instead of only having the OS version it could contain distro than version and the leaf would point to the native package for that distribution.

Distro could be selected by best match. E.g. imagine there are packages for ubuntu and debian. If I'm using Ubuntu the package under bottles.ubuntu.[my version] is selected, while if I'm on Kali it will select 'debian'.

I'm suggesting this because I started creating formula manifests for Comtrya so I can easily move from one distro to another and that's exactly how I choose between rpm, deb, etc.

For developers, the impact on performance of using snaps or flatpacks is not negligible (at least for me). But installing all needed packages buy hand is a hassle and having that on brew would be a life saver!

[SMillerDev]

I think you've just reinvented things like https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.pkg.html or https://docs.ansible.com/ansible/latest/collections/ansible/builtin/package_module.html

[svallory]

@SMillerDev no, I didn't. I see why it looks like it though. but comtrya is a single executable inside my git backed .dotfiles folder.

I'd never heard of salt, but I'm not installing ansible just to set up a new install if I won't use it later. Also, this single writing this zsh.yml manifest is waaaay simpler that using ansible:

actions:
    
  - action: package.install
    names: zsh
    where: os.name == "MACOS"
    provider: Homebrew

    variants:
      - where: '["Debian", "Linux Mint", "Pop!_OS", "Ubuntu"].contains os.distribution'
        names: zsh
        provider: aptitude

      - where: '["Arch Linux", "Manjaro"].contains os.distribution'
        names: zsh
        provider: yay

      - where: '["DragonFly BSD", "FreeBSD"].contains os.distribution'
        names: zsh
        provider: BsdPkg

      - where: os.name == "linux"
        names: zsh
        provider: aptitude

      - where: os.name == "windows"
        names: zsh
        provider: winget

[jcrben]

Preliminary support for Linux casks shipped in 4.5.0

https://brew.sh/2025/04/29/homebrew-4.5.0/