Brew packages should be casks, not formulae

[SMillerDev]

In Homebrew parlance, a formula builds from source and a cask is pre-compiled: https://docs.brew.sh/Formula-Cookbook#homebrew-terminology

GoReleaser creates formulae, despite the packages being precompiled, which causes confusion in the usage for Homebrew users. While previously casks were not supported on Linux, since Homebrew/brew#19121 they are so GoReleaser can now provide casks for all pre-compiled binaries.

[caarlos0]

so, basically, we replace the < Formula with < Cask?
What does this change entails?
Would it break anything?

[caarlos0]

looking into this again - so, after the recent changes, basically the only thing we need to change is the cask "foo" do and the default Casks directory? is that correct?

PS: working on it rn

[caarlos0]

answering myself, there are more changes. I made some of them in here: #5780

Feel free to take a look if/when you can.

Very WIP still btw

[cafferata]

I'd like to jump in on @caarlos0's earlier work regarding the Homebrew (Cask) integration. I've set up a working configuration for DNSControl, and while the initial Cask setup seems to work (with a few minor improvements), DNSControl is a CLI tool and should be distributed as a Formula rather than a Cask. Casks are intended for GUI applications or tools installed via .pkg, .app, or .dmg, whereas CLI tools belong in Formulae.

In the new setup, I haven't been able to get a working Formula. I might have missed something in the existing GitHub pull requests or discussions?

Happy to share my Homebrew knowledge and help test the DNSControl setup, which has been on my to-do list. Let me know how I can contribute.

Here's the installation command and the error I encountered:

$ brew install dnscontrol/tap/dnscontrol

==> Tapping dnscontrol/tap
Cloning into '/usr/local/Homebrew/Library/Taps/dnscontrol/homebrew-tap'...
remote: Enumerating objects: 21, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 21 (delta 4), reused 3 (delta 1), pack-reused 0 (from 0)
Receiving objects: 100% (21/21), 4.10 KiB | 1.37 MiB/s, done.
Resolving deltas: 100% (4/4), done.
Tapped 1 formula (13 files, 11.0KB).
Error: dnscontrol/tap/dnscontrol: undefined method 'cask' for module Formulary::FormulaNamespace6ca7b15f753de59be9e824a2aa5a59f0c3468c154b19490f7dab7fa84b05dc65

For reference, here's the (broken) Formula that was generated DNSControl/homebrew-tap/Formula/dnscontrol.rb:

# This file was generated by GoReleaser. DO NOT EDIT.
cask "dnscontrol" do
  desc "DNSControl: Infrastructure as Code for DNS Zones"
  homepage "https://docs.dnscontrol.org/"
  version "4.20.1"
  license "MIT"

  livecheck do
    skip "Auto-generated on release."
  end

  binary "dnscontrol"

  on_macos do
    url "https://github.com/DNSControl/dnscontrol/releases/download/v4.20.1/dnscontrol_4.20.1_darwin_all.tar.gz"
    sha256 "39bed97a1183934c4e5bb1706ff4e2b954bdf83437cd1bf7e4db23904134f30e"
  end

  on_linux do
    on_intel do
      url "https://github.com/DNSControl/dnscontrol/releases/download/v4.20.1/dnscontrol_4.20.1_linux_amd64.tar.gz"
      sha256 "ae7c66c4f3424329415863f136dee727e21a84e9c05c00fbc7a2af07fe027089"
    end
    on_arm do
      url "https://github.com/DNSControl/dnscontrol/releases/download/v4.20.1/dnscontrol_4.20.1_linux_arm64.tar.gz"
      sha256 "1516b5071b9e4ceb4bea2875617610ad43b6382ca39256e71508821b63b943db"
    end
  end

  conflicts_with formula: "dnscontrol"

  # No zap stanza required
end

This was generated using the following GoReleaser configuration DNSControl/dnscontrol@2e7ebc2:

homebrew_casks:
  -
    name: dnscontrol
    url:
      template: "https://github.com/DNSControl/dnscontrol/releases/download/{{ .Tag }}/{{ .ArtifactName }}"
    commit_author:
      name: goreleaserbot
      email: bot@goreleaser.com
    commit_msg_template: "Brew cask update for {{ .ProjectName }} version {{ .Tag }}"
    directory: Formula
    homepage: "https://docs.dnscontrol.org/"
    description: "DNSControl: Infrastructure as Code for DNS Zones"
    license: "MIT"
    conflicts:
      - formula: dnscontrol
    repository:
      owner: dnscontrol
      name: homebrew-tap
      branch: main
      token: "{{ .Env.HOMEBREW_TAP_TOKEN }}"

You can find the relevant commits I've made here:
https://github.com/DNSControl/dnscontrol/commits/main/?author=cafferata&since=2025-06-01&until=2025-06-03

Is it correct that the Homebrew Formula setup isn't currently functional? Was this perhaps overlooked? How can I help move this forward? Please feel free to let me know.

[SMillerDev]

DNSControl is a CLI tool and should be distributed as a Formula rather than a Cask. Casks are intended for GUI applications or tools installed via .pkg, .app, or .dmg, whereas CLI tools belong in Formulae.

This is not correct. Open source software should be build as a formula. Prebuilt binaries should be distributed as a cask. It's just that a lot of prebuilt binaries are GUI applications.

[caarlos0]

For reference, here's the (broken) Formula that was generated DNSControl/homebrew-tap/Formula/dnscontrol.rb:

I think that the problem there is that the cask is in the Formula folder, it should be in Casks.
You can remove directory: Formula from your configuration.

[sushichan044]

@caarlos0
One concern is that distributing binaries via Cask requires code signing for macOS.
While this is appropriate, code signing even simple internal CLI tools is quite laborious.

Distributing as a Formula, though not its intended use, circumvented this problem.
While Homebrew Formula support is deprecated, will it be removed in v3?

[caarlos0]

thanks, again, @SMillerDev 🙏🏻

[SMillerDev]

Damned, I missed a line.

If you don't want to do any of the steps above, you may want to instruct your users to use ctrl+click the binary/app and select "Open" from the context menu, or alternatively, to run the appropriate xattr command manually.

The ctrl+click doesn't work on ARM macs as far as I know, removing the quarantine bit is the only way.

[caarlos0]

hmmm I think I did that a while ago and it worked? Might be misremembering though - will update the docs. Thanks again!

[SMillerDev]

Should have checked the Homebrew docs first. https://docs.brew.sh/FAQ#why-cant-i-open-a-mac-app-from-an-unidentified-developer

"Unidentified developer" is the message on intel, which can be bypassed. "This app is damaged" is the message on ARM and can not be easily bypassed.

[caarlos0]

I guess it's fine anyway, just a matter of time until apple make it more difficult

[caarlos0]

FWIW, it seems conflicts_with and depends_on can't be repeated? My manual live tests only had one dep/conflict, so I didn't catch it.. caught it live instead :kek:

also had a typo in the completions stuff

and finally, seems like license is not supported by casks?

cc/ @SMillerDev

291534e

[SMillerDev]

No, they can definitely be repeated. Where did you see it can't? What was the error?
The license might be correct.

[caarlos0]

might have been me being crazy, it probably actually complained about the lack of quotes around the dependency name

in either case, it should be now fixed

[caarlos0]

@SMillerDev another question I have about the migration: is there a way to instruct users to uninstall the formula and install the cask instead?

[caarlos0]

or, related: if I delete the formula folder from the tap, what happens to people that already have the formula installed?

[caarlos0]

@SMillerDev I think I might have found a bug in casks!

see https://github.com/goreleaser/homebrew-tap/blob/master/Formula/goreleaser.rb and https://github.com/goreleaser/homebrew-tap/blob/master/Casks/goreleaser.rb

The cask has the conflicts_with block, but, if you had the formula installed, and try to install the cask, it doesn't say it conflicts or anything, and tries to install it anyway:

$ HOMEBREW_AUTO_UPDATE_SECS=1 brew upgrade
==> Auto-updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (goreleaser/tap).

You have 1 outdated formula installed.

==> Upgrading 1 outdated package:
goreleaser/tap/goreleaser 2.9.0 -> 2.9.1
Error: goreleaser/tap/goreleaser has been disabled because it the cask should be used now instead! It will be disabled on 2025-06-14.
Replacement:
  brew install --cask goreleaser

$ brew install --cask goreleaser/tap/goreleaser
==> Downloading https://github.com/goreleaser/goreleaser/releases/download/v2.10.2/goreleaser_Darwin_arm64.tar.gz
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/77071454/08a37aaf-7bf5-4615-a1e5-dcd6b5458d88?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetprodu
############################################################################################################################################################################################################ 100.0%
==> Installing Cask goreleaser
==> Purging files for version 2.10.2 of Cask goreleaser
Error: It seems there is already a Binary at '/opt/homebrew/bin/goreleaser'.

I think it should say that a formula that is already installed conflicts with the cask instead?

[caarlos0]

Now that I know it isn't, I might give it a shot.

let me know if I can help in any way!

[caarlos0]

@SMillerDev any news on making replaces work on casks?

[SMillerDev]

Unfortunately nothing yet.

[caarlos0]

Is there an open issue/PR I could subscribe to? Tried to search but didn't find it...

[SMillerDev]

Officially it's Homebrew/homebrew-cask#12822

[mprimeaux]

I know this issue is closed but I tried to migrate from the brews stanza to homebrew_casks stanza and I'm having various issues in doing so with the most concerning migration point being that casks are not supported on Linux by brew. I'm sure I'm missing something so any help is greatly appreciated.

The CLI I have is the NanoID client and the corresponding homebrew repo is here.

Essentially, I broke everyone with what has worked before on macOS and Linux:

brew tap sixafter/tap
brew install nanoid

I'm sure I'm doing something silly. Any insights are welcome.

[SMillerDev]

casks are not supported on Linux by brew

They are, I implemented support for the goreleaser cases myself. If brew is telling you they are not you're probably on a very old version of it and should run brew update

[mprimeaux]

@SMillerDev Thanks much for your help. I'll check with the person who reported the failure to me and look at migrating to the homebred_casks stanza. Appreciate it.

[mprimeaux]

@SMillerDev As an update, it turned out that brew was grossly outdated on the target machine.

I've now implemented homebrew_casks: and it works great. I also decided to leave the brews: stanza in for now and added the deprecation notice in the related README.md. Thanks again for your help.

[SMillerDev]

Glad to hear it worked now.

[dorianm]

Hello, It looks like there is an incompatibility between the new homebrew_casks and the binary archive format.

In my current GoReleaser config, I use this configuration to get only binary as artifact :

archives:
  - formats:
      - "binary"

Then I push this artifact to a S3 bucket, and use it with homebrew_casks like this:

blobs:
  - provider: s3
    region: eu-west-3
    bucket: my-company-release

homebrew_casks:
  - name: foo
    directory: Casks
    conflicts:
      - formula: foo
    url:
      template: https://my-company-release.s3.eu-west-3.amazonaws.com/{{.ProjectName}}/{{.Tag}}/foo_{{.Version}}_linux_amd64
    commit_author:
      name: "{{ .Env.GITLAB_USER_NAME }}"
      email: "{{ .Env.GITLAB_USER_EMAIL }}"
    repository:
      owner: foo
      name: homebrew-tap
      token: "{{ .Env.GITLAB_TOKEN }}"

Everything works fine at compile/package, I got my new formule which looks like this:

# This file was generated by GoReleaser. DO NOT EDIT.
cask "foo" do
  desc "Foo"
  homepage "https://gitlab.com/foo/foo"
  version "2.3.4"

  livecheck do
    skip "Auto-generated on release."
  end

  binary "foo"

  on_linux do
    on_intel do
      url "https://my-company-release.s3.eu-west-3.amazonaws.com/foo/v2.3.4/foo_2.3.4_linux_amd64"
      sha256 "<redacted>"
    end
  end

  conflicts_with formula: [
      "foo",
    ]

  # No zap stanza required
end

And when I run brew install --cask foo, I get the following error:

==> Downloading https://formulae.brew.sh/api/cask.jws.json
==> Downloading https://my-company-release.s3.eu-west-3.amazonaws.com/foo/v2.3.4/foo_2.3.4_linux_amd64
Already downloaded: /home/me/.cache/Homebrew/downloads/<redacted-id>--foo_2.3.4_linux_amd64
==> Installing Cask foo
==> Purging files for version 2.3.4 of Cask foo
Error: It seems the symlink source '/home/linuxbrew/.linuxbrew/Caskroom/foo/2.3.4/foo' is not there.

I try to update manually my Formula (with brew edit) to remove binary at root level and put it with a target in my os/arch level:

# This file was generated by GoReleaser. DO NOT EDIT.
cask "foo" do
  # [...]

  # binary "foo"

  on_linux do
    on_intel do
      url "https://my-company-release.s3.eu-west-3.amazonaws.com/foo/v2.3.4/foo_2.3.4_linux_amd64"
      sha256 "<redacted>"
      binary "foo_2.3.4_linux_amd64", target: "foo"
    end
  end

  # [...]
end

With this modification it works fine. Unfortunately, I think I can't generate it like this with the current configuration. I consider using archive artifact (like it's done in the GoReleaser own project configuration) to bypass this limitation. Do you have any other idea?

Thank you in advance.

[SMillerDev]

I'm not sure why it thinks the binary should be called foo. But an archive with a foo binary in it seems reasonable to me.

[dorianm]

Thank you for your answer @SMillerDev. foo is my project name, and binary use cask name as default config, that's why the binary is called foo in my case 🤔

I'll change my archive format to test with a simple .tag.gz file, it should work out of the box if I understand correctly.

[caarlos0]

that looks like a bug indeed!

[dorianm]

Ok so I dig a bit more, it works fine with a .tar.gz archive. This is a workaround:

#[...]
archives:
  - id: binary
    formats:
      - binary
  - id: targz
    formats:
      - tar.gz

blobs:
  - provider: s3
    region: eu-west-3
    bucket: my-company-release

homebrew_casks:
  - name: foo
    directory: Casks
    # Conflicts with the previous Formula (see https://goreleaser.com/deprecations/#brews)
    conflicts:
      - formula: foo
    ids:
      - targz
    description: Foo app
    homepage: https://gitlab.com/foo/foo
    url:
      template: https://my-company-release.s3.eu-west-3.amazonaws.com/{{.ProjectName}}/{{.Tag}}/foo_{{.Version}}_linux_amd64.tar.gz
    commit_author:
      name: "{{ .Env.GITLAB_USER_NAME }}"
      email: "{{ .Env.GITLAB_USER_EMAIL }}"
    repository:
      owner: foo
      name: homebrew-tap
      token: "{{ .Env.GITLAB_TOKEN }}"

I need to keep access to my binary directly in S3 (for another use case, not related to Homebrew at all), so now I have both files uploaded and available in S3, it works fine.

I used the brew stanza before, and it worked fine because the Formula contained a custom instruction to install (bin.install "foo_2.3.0_linux_amd64" => "foo"):

# typed: false
# frozen_string_literal: true

# This file was generated by GoReleaser. DO NOT EDIT.
class Foo < Formula
  # [...]

  if Hardware::CPU.intel?
    if Hardware::CPU.is_64_bit?
      url "https://my-company-release.s3.eu-west-3.amazonaws.com/foo/v2.3.0/foo_2.3.0_linux_amd64"
      sha256 "<redacted>"

      def install
        bin.install "foo_2.3.0_linux_amd64" => "foo"
      end
    end
  end
end

[caarlos0]

see #5840

[yermulnik]

Given it's not a simple task to engage and educate all users at once to switch from brew install … to brew install --cask …, would it — pretty please — be possible to switch brews deprecation from an error to a notice or a warning to let goreleaser check exit with zero exit code instead of failing to allow linter bundles like https://github.com/super-linter/super-linter to not fail because of this change in Goreleaser?
Thanks in advance 🙏🏻

> goreleaser check
  • checking                                  path=.goreleaser.yml
  • DEPRECATED: brews should not be used anymore, check https://goreleaser.com/deprecations#brews for more info
  • .goreleaser.yml                                  error=configuration is valid, but uses deprecated properties
  ⨯ check failed                                     error=1 out of 1 configuration file(s) have issues

> podman run -e RUN_LOCAL=true -e VALIDATE_GO_RELEASER=true -e FILTER_REGEX_INCLUDE="^$PWD/.goreleaser" --name super-linter --env GITHUB_WORKSPACE="$(git rev-parse --show-toplevel)" -v "$(git rev-parse --show-toplevel):$(git rev-parse --show-toplevel)" -v "$(git rev-parse --git-common-dir):$(git rev-parse --git-common-dir)" --workdir "$(git rev-parse --show-toplevel)" --rm ghcr.io/super-linter/super-linter:slim-latest
2025-07-24 15:00:52 [INFO]   --------------------------------------------------------------------------------
[snip]
2025-07-24 15:00:52 [INFO]   This version of Super-linter includes the following tools:
[snip]
[GO_RELEASER] goreleaser: 2.11.0
[snip]
2025-07-24 15:01:01 [INFO]   Command output when running linters:
------
2025-07-24 15:01:01 [INFO]   Linting GO_RELEASER items...
2025-07-24 15:01:01 [ERROR]   Found errors when linting GO_RELEASER. Exit code: 1.
2025-07-24 15:01:01 [INFO]   Stderr contents for GO_RELEASER:
------
  • checking                                  path=/home/[snip]/.goreleaser.yml
  • DEPRECATED: brews should not be used anymore, check https://goreleaser.com/deprecations#brews for more info
  • /home/[snip]/.goreleaser.yml error=configuration is valid, but uses deprecated properties
1 out of 1 configuration file(s) have issues
------
------
2025-07-24 15:01:01 [INFO]   ----------------------------------------------
2025-07-24 15:01:01 [INFO]   ----------------------------------------------
2025-07-24 15:01:02 [ERROR]   Errors found in GO_RELEASER
2025-07-24 15:01:02 [ERROR]   Super-linter detected linting errors

[yermulnik]

@caarlos0 Wow, that was fast and looks great (both PRs). Appreciate it! 🙏🏻

[yermulnik]

@caarlos0 I can't seem to find this info: what's the release cadence (as in what is an approximate date for the release that will include #5924)? Thanks.

[caarlos0]

patch release is being built right now :)

[yermulnik]

Thank you.

[yermulnik]

Unless your have a cask with the same name as a formula, brew install works just fine. If you do have a conflict brew will default to the formula, and only then you need --cask to specify that you want a cask.

I've just come across this and the learning is that --cask looks to be a requirement on Linux (as mentioned in this comment of yours).
You can find repro at suzuki-shunsuke/ghtkn#7 (comment)

[caarlos0]

Another issue with using casks: entitlements

macOS might simply kill the process, even if signed & notarized, because some entitlement is missing.

It's always super helpful that it doesn't say which, just SIGKILL, and logs nothing about it either.

Anyway, at this point I'm considering un-deprecating brews... its just too much work to get casks to work properly, and its always a surprise because its hard to debug these things as well...

[caarlos0]

So, can I add something like this to goreleaser/homebrew-tap:

{
  "goreleaser": "goreleaser/tap/Casks/goreleaser"
}

and it would work? 🤔

[SMillerDev]

it would be "goreleaser": "goreleaser/tap/goreleaser" since it's not a file path. But I'm not 100% sure that would work. You'd have to try it to be sure. Maybe you can rename the formula first and then do the migration? We're in uncharted territory here with a formula and a cask in the same tap with the same name.

[caarlos0]

what happens to people that already have the formula installed?

We're in uncharted territory here with a formula and a cask in the same tap with the same name.

good thing about this is that we can write some sort of "manual" of sorts for the next folk that stumble into the same issue 🙏

[SMillerDev]

Homebrew/brew#20585 would help here. Unfortunately it seems that there is no existing way to do this in brew.

[caarlos0]

that one would be awesome indeed!

[mprimeaux]

@caarlos0 See the Homebrew section my README.md for the xattr command line to remove the quarantine block on your related executable. A bit frustrating no doubt but this will enable you to test.

[yermulnik]

I guess there's a diff between app entitlements and extended file attributes:

In macOS, entitlements are a mechanism that grants an application specific permissions, enabling it to perform actions beyond what its sandbox or standard user permissions would normally allow. Extended file attributes (xattrs), on the other hand, are pieces of metadata associated with files and directories that store additional information beyond standard attributes like name, size, and permissions.

[caarlos0]

xattr won't fix it I'm afraid...

[mprimeaux]

xattr will address the issue until the next upgrade or re-installation of the target executable. Notarizing it will address the issue in a more permanent way as here.

[gibfahn]

It's mentioned in earlier threads, but I wanted to clarify what the expected migration path is.

By default we assume that brew install my-org/tap/my-formula will work, because there's only one thing with that name. However when doing this Goreleaser migration you have two choices:

1. Delete the Formula when you add the Cask

For new users brew install my-org/tap/my-formula still works as expected.
Existing users will get an error when they try to brew upgrade.

2. Keep both, disable the formula

i.e. add a line to the Formula like:

disable! date: "2025-08-07", because: "the cask should be used now instead", replacement_cask: "my-formula"

This means that every user running the original command will get output like this:

Warning: Treating my-org/tap/my-formula as a formula. For the cask, use my-org/tap/my-formula or specify the `--cask` flag. To silence this message, use the `--formula` flag.
==> Fetching downloads for: my-formula
Error: my-org/tap/my-formula has been disabled because it the cask should be used now instead! It was disabled on 2025-08-07.
Replacement:
  brew install --cask my-formula

and have to manually take action for every formula they have installed. I've already seen users having issues with both.

Proposal

Maybe brew can special-case brew upgrade so that if the formula has been replaced with a cask of the same name, it handles the migration? Over time I think we want to keep things easier for new users, and having to add --cask everywhere isn't ideal.

Alternatively maybe formula_renames.json could be extended to handle this.

[gibfahn]

(I realise @caarlos0 already asked this in https://github.com/orgs/goreleaser/discussions/5563#discussioncomment-13404578)

[gibfahn]

Also for what it's worth I got some suggestions here from homebrew maintainers in Homebrew/brew#20291 (comment):

2. Folks are Cask to Formula but keeping both around (with one disabled), this means you now have to brew install --cask instead of just brew install . It's also a migration for all users of the cask.

Report this to tap authors. This is not a Homebrew recommended workflow. Several options exist including deleting the formula, using tap_migrations.json to migrate from formula to cask or using different names.

These UX regressions are happening because Homebrew is telling the GoReleaser folks they should be using casks, but also the homebrew project doesn't mind what 3rd party taps do?

We have opinions. We are not forcing anyone to do anything.

This suggest we can use tap_migrations.json to migrate from formula → cask, but I can't see a way to do it in the docs. In upstream homebrew it's easy because formula and casks are different taps (homebrew/core vs homebrew/cask), but that doesn't really make sense for 3rd-party taps.

[brejoc]

I have to admit that I’m a bit surprised by the deprecation of formulas, and casks being suggested over bottles. When has this shift at homebrew happened? homebrew-cask still mentions gui applications as the use case, while bottles are mentioned to deal with “Binary Packages”.

Perhaps I should have mentioned this at homebrew upstream, but I ran into this in the context of goreleaser.

[brejoc]

Also afaik bottles don’t require code signing, since they don’t rely on macOS’s app notarisation flow. Wouldn’t that significantly reduce complexity?

[SMillerDev]

Bottles are Homebrew OCI container format images with special variables to allow for relocation of binaries. It's not just any binary.
Casks do allow any binary, but have a focus on GUIs on top of that, because that's a type of binary that often doesn't have an easy install method.

[SMillerDev]

Essentially, bottles are what homebrew CI flows output and therefore brew does special tricks to pretend it's signed. They are not just any binary.

[caarlos0]

@SMillerDev Hey! Sorry to bother, but I have another question.

In GoReleaser, it is possible to have archives with a dir in them, e.g. foo-linux-amd64.tgz can have a folder foo-linux-amd64 inside it, which contains the binary.

What's the best way to handle that in a Cask? Can we set a directory inside the archive? I was thinking about doing something like this, but then I would also have to do it for manpages, completions, etc, which felt a bit wrong.

Another problem when migrating from formula is that it was easy to generate completions in a post install script for formula, but apparently it doesn't work with casks.

For reference: https://github.com/orgs/goreleaser/discussions/6214 https://github.com/orgs/goreleaser/discussions/6212 https://github.com/orgs/goreleaser/discussions/6245

[SMillerDev]

For the directories, I guess you can use https://docs.brew.sh/Cask-Cookbook#flight-mini-dsl to normalise the directory before it runs the actual install.

[caarlos0]

not sure i follow the mini DSL thing - could you elaborate?

is the idea to mv foo-* foo for example? can i use globs there?

[caarlos0]

oh - and thanks for the issue for the completions <3

[SMillerDev]

Here's an example of preflight DSL usage: https://github.com/Homebrew/homebrew-cask/blob/dc0f1f2360b4448a794009fb926d310a4161e03d/Casks/v/vlc.rb#L26 but you can also run other ruby code in them. You could do mv Dir["some-dir-#{version.major}-*"], "."

[caarlos0]

oh, awesome, will play with that

[dirien]

Hey @caarlos0,

I wanted to share a practical concern from the user side.

I maintain a CLI tool (lazy-pulumi) and initially used homebrew_casks as recommended. But I got feedback from users that brew upgrade was not picking up new versions. They had to run brew upgrade --cask or brew upgrade --greedy to get updates.

For CLI tools this is a problem. Most users just run brew upgrade and expect everything to update. With casks using version :latest or having auto-update flags, updates can be silently skipped. Formulas dont have this issue.

I understand the terminology argument (formula = source, cask = binary). But from a user experience perspective, CLI tools distributed as casks can miss updates. This is why I consider to switch back to brews for my project.

Maybe worth considering:

Keep brews as a supported option for CLI tools
Or document this upgrade behavior difference more clearly

[SMillerDev]

Is the cask marked as auto updating or without a version? If not, this sounds like a regression in Homebrew and should be reported there. Apart from casks that auto update or are marked latest, the update mechanism should work absolutely the same between casks and formula.

[SMillerDev]

With casks using version :latest or having auto-update flags, updates can be silently skipped. Formulas dont have this issue.

It seems I missed this. I think it's not up to goreleaser to make people understand what they are distributing.

If you opt out of updatability in brew, brew will not update your software. It's a feature. Maybe goreleaser could warn you about it, but it's just as easy to shoot yourself in the foot with formula.

In fact, the way goreleaser uses formula is so out of the ordinary, it's a wonder it doesn't break often.

[caarlos0]

It seems I missed this. I think it's not up to goreleaser to make people understand what they are distributing.

agreed.