Improve error/warning when brew install refuses to install a formula from a tap with the same name as an already installed keg

[9999years]

(Reworded by @MikeMcQuaid)

What did you expect to happen?

I expected Homebrew to be able to install two formulae with the same name from different taps. When this didn't work, I expected the error message to reference this

Step-by-step reproduction instructions (by running brew commands)

$ brew uninstall -f mercurytechnologies/tap/postgresql@16 homebrew/homebrew-core/postgresql@16
Uninstalling postgresql@16... (3,801 files, 68.4MB)

$ brew install homebrew/homebrew-core/postgresql@16
==> Downloading https://ghcr.io/v2/homebrew/core/postgresql/16/manifests/16.3
...
==> Summary
🍺  /opt/homebrew/Cellar/postgresql@16/16.3: 3,801 files, 68.4MB

$ brew install mercurytechnologies/homebrew-tap/postgresql@16
Warning: mercurytechnologies/tap/postgresql@16 16.3 is already installed, it's just not linked.
To link this version, run:
  brew link postgresql@16

Further, brew info will incorrectly claim that mercurytechnologies/tap/postgresql@16 is installed.

$ brew info mercurytechnologies/tap/postgresql@16
==> mercurytechnologies/tap/postgresql@16: stable 16.3
Object-relational database system
https://www.postgresql.org/
Installed
/opt/homebrew/Cellar/postgresql@16/16.3 (3,801 files, 68.4MB)
  Poured from bottle using the formulae.brew.sh API on 2024-08-02 at 12:35:48
From: https://github.com/MercuryTechnologies/homebrew-tap/blob/HEAD/Formula/postgresql@16.rb
License: PostgreSQL
==> Dependencies
Build: pkg-config ✔
Required: gettext ✔, icu4c ✔, krb5 ✔, lz4 ✔, openssl@3 ✔, readline ✔, zstd ✔
==> Caveats
This formula has created a default database cluster with:
  initdb --locale=C -E UTF-8 /opt/homebrew/var/postgresql@16
For more details, read:
  https://www.postgresql.org/docs/16/app-initdb.html

To start mercurytechnologies/tap/postgresql@16 now and restart at login:
  brew services start mercurytechnologies/tap/postgresql@16
Or, if you don't want/need a background service you can just run:
  LC_ALL="C" /opt/homebrew/opt/postgresql@16/bin/postgres -D /opt/homebrew/var/postgresql@16
==> Analytics
install: 6,224 (30 days), 20,812 (90 days), 62,627 (365 days)
install-on-request: 6,117 (30 days), 20,368 (90 days), 60,669 (365 days)
build-error: 11 (30 days)

Related issues

• Wrong tap when listing installed casks from custom taps using --json=v2 --installed #17416 noticed this issue with brew info --json=v2 --installed, but didn't notice that brew install suffers the same flaw
• Avoid duplicate names/"shadowing" in homebrew/core and homebrew/cask #17560 deals with shadowing, but only in homebrew/core and homebrew/cask
• How should we store installed cask information? #17013 discusses how information about installed casks is stored, and storing the tap a cask is installed from is mentioned
• Tangentially: brew deps output shows inconsistent dependency information between tree and non-tree output #16032

[Bo98]

I assumed that the tap name serves as a namespace to disambiguate the two casks and allow them to coexist.

It allows them to co-exist as a distinct installable items but it does not allow for both of them to be installed at the same time. This applies to both formulae and casks.

You can see that formulae are installed to $HOMEBREW_PREFIX/Cellar/<name> and that name is not a fully-qualified name. Similarly for casks: $HOMEBREW_PREFIX/Caskroom/<name>.

[MikeMcQuaid]

As @Bo98 said. This is a WONTFIX, unfortunately, it's baked too hard into the Homebrew internals to realistically ever change it. The best workaround is to rename the formulae in your tap.

[9999years]

Hm, I think it's a fine constraint to not allow two formulae with the same name to be installed at once, but I think the error message should indicate that — "a formula with the same name from tap ... is installed".

Also, I think we should have some callouts to this fact in the Homebrew documentation, which currently don't indicate that this is an issue.

[apainintheneck]

I agree this should be better documented somewhere and the error message could be improved as well.

[MikeMcQuaid]

Apologies for the confusion @9999years, this issue should not have been reopened yet.

I agree the documentation could be improved here but I don't think this issue as-is is the best way of describing the problem that needs addressed.

@9999years are you ok if I rework the original issue body to describe the (new) problem(s) that should be fixed here or would you rather a new issue is opened that is not attributed to you? Thanks!

[9999years]

Feel free to rework the issue body, the template seemed really strict so I didn't want to "break the rules"

[MikeMcQuaid]

Thanks @9999years, done now!