Yeah, I think this falls in the same category as git, svn, easy_install, and (in some cases) powershell, where we provide resources that depend on functionality that isn’t available out of the box. It’s a bit weird that this is a package resource that requires extra config before you can use it, but that’s OS X for you.
On Friday, July 25, 2014 at 12:24 PM, Joseph Anthony Pasquale Holsten wrote:
We haven’t needed to add macports to the omnibus-client or dev toolchain. I think the same is true for homebrew.
On Jul 25, 2014, at 11:26 AM, Matt Ray <email@example.com (mailto:firstname.lastname@example.org)> wrote:
If the default package manager is Homebrew, does this mean we need to
add it to the omnibus-client package for OSX? What about the whole OSX
Director of Partner Integration :: Chef
512.731.2218 :: email@example.com (mailto:firstname.lastname@example.org)
mattray :: GitHub :: IRC :: Twitter
On Thu, Jul 24, 2014 at 3:41 AM, Waldo G <email@example.com (mailto:firstname.lastname@example.org)> wrote:
On Thu, Jul 24, 2014 at 2:08 AM, Dreamcat4 <email@example.com (mailto:firstname.lastname@example.org)> wrote:
On Thu, Jul 24, 2014 at 5:28 AM, Joseph Anthony Pasquale Holsten
<email@example.com (mailto:firstname.lastname@example.org)> wrote:
I may be a MacPorts package maintainer, but this is the right default. +1
On Jul 24, 2014, at 3:17, Joshua Timberman <email@example.com (mailto:firstname.lastname@example.org)> wrote:
I opened an issue in chef-rfc about making homebrew the default provider
for the package resource on OS X systems.
While I’d like to see this happen for Chef 12, I think given the
backwards compatibility issue makes that too aggressive. I’d love to hear
folks thoughts though. Please comment!