Packages with an alias/alternate name get installed repeatedly.

[zbentley]

If I have:

package { 'mosh':
    provider => homebrew;
}

It installs successfully on the first puppet run, and then reinstalls on every subsequent run.

This is because mosh is actually an alias/alt-name for the package mobile-shell, so brew list --versions mosh returns nothing, but brew search mosh indicates that it's installed.

This might actually be an issue with Homebrew (if so let me know and I'll find/link/report it there). It can be worked around by checking for installed-ness via the success of brew info $package | grep '^Not installed$ (or the Ruby equivalent), logical-or the failure of the brew info command (package name doesn't exist). The info subcommand honors/follows alternate names, with brewcask as well as brew. However, this probably breaks the ability to use this module offline (no idea if that was important to begin with), since I don't think brew list needs the internet to get data about modules, but brew list does, especially if a module isn't found.

[TheKevJames]

Huh. Well, that's not great.

Looks like this is an issue with puppet-homebrew rather than brew itself. We should be able to look up the aliases in a few different ways and keep that in mind when deciding whether or not to install.

---

Notes-to-self:

See:

[kevinc@atomicbox(zsh):/usr/local] brew install mosh
==> Installing dependencies for mobile-shell: protobuf
==> Installing mobile-shell dependency: protobuf
==> Downloading https://homebrew.bintray.com/bottles/protobuf-3.1.0.el_capitan.bottle.tar.gz
######################################################################## 100.0%
==> Pouring protobuf-3.1.0.el_capitan.bottle.tar.gz
==> Caveats
Editor support and examples have been installed to:
  /usr/local/Cellar/protobuf/3.1.0/share/doc/protobuf
==> Summary
🍺  /usr/local/Cellar/protobuf/3.1.0: 253 files, 16M
==> Installing mobile-shell
==> Downloading https://homebrew.bintray.com/bottles/mobile-shell-1.2.6_3.el_capitan.bottle.tar.gz
######################################################################## 100.0%
==> Pouring mobile-shell-1.2.6_3.el_capitan.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
  /usr/local/etc/bash_completion.d
==> Summary
🍺  /usr/local/Cellar/mobile-shell/1.2.6_3: 13 files, 939.2K
[kevinc@atomicbox(zsh):/usr/local] brew install mosh
Warning: mobile-shell-1.2.6_3 already installed

I can't find an easy way to look up homebrew aliases. It looks like homebrew creates aliases manually, which makes it unlikely they've built a way to look these up automatically. This may help, but I'm not yet sure how to use this.

It looks like homebrew core knows about these, probably somewhere in the update payload. In /usr/local/Homebrew, we seem to only have Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/mosh.rb and Homebrew/Library/Taps/homebrew/homebrew-core/Formula/mobile-shell.rb... the latter would be the one we want to look at, but it looks like it's only a one-way lookup.

brew list mosh in the case where mosh is not installed returns this alias (Error: No such keg: /usr/local/Cellar/mobile-shell), but that doesn't help us too much since it shows paths only when the package is installed.

Regardless of whether mosh is installed, the first line of info returns it's real name:

[kevinc@atomicbox(zsh):/usr/local] brew info mosh
mobile-shell: stable 1.2.6 (bottled), HEAD
# snip

Output parsing is gross, but it might be helpful in this case.

---

[zbentley]

Radical and probably-bad (haven't thought about it too hard) idea: do brew install during the existence check phase. An "already-installed" result (happens quickly for installed packages) results in an existence-check-success. An "installing...installed" successful operation (as is currently done during the "install" phase) results in a no-op/notify install operation. An error gets captured and re-thrown during the "install" phase.

[zbentley]

While this module can and maybe should handle this case, it does seem like a useful feature to have in Homebrew itself, if only for consistency with how other subcommands behave. I opened Homebrew/brew#1514 for this.

[edestecd]

This behavior is the same with the yum provider and aliases. Just don't use the alias. Use the real package name.

[TheKevJames]

@zbentley It looks like this is now fixed due to Homebrew/brew#1520, please feel free to reopen the issue if that is not the case.

[zbentley]

Seems to be working now. Thanks!