[chef-dev] Re: paths as native attributes in chef or ohai?

[Joseph Holsten < >]

On 2013-09-12, at 18:59, Blake Irvin 
<
 >
 wrote:

> One thing I love about Chef is that it shines a light on long-standing 
> issues in systems management that the community has historically ignored 
> because our environments are often very different.  By holding out the 
> promise of a cross-platform, multi-environment abstraction layer, Chef gets 
> us thinking about ways to make things better.
> 
> The number one issue I run into when using a cookbook written for and 
> tested on platform X on platform Y is that X and Y don't keep userland 
> binaries/libs/configuration files in the same places/paths.  Despite all 
> our efforts to make cookbooks data/attribute driven, we still hard-code 
> paths all over the place.
> 
> Here's my attempt at a remedy for this:  
> https://github.com/wanelo-chef/paths
> 
> With some more work, this cookbook can be highly intelligent about setting 
> paths (like looking at package manager configs to figure out our default 
> prefix/path for packages).
> 
> Is this something that we want in ohai/chef rather than a cookbook?  Do we 
> want to encourage the community at large to use attribute-driven pathing?  
> (I think we do).


I personally standardize on the gnu coding standard/autotools names:

    localstatedir: '/var',
    sysconfdir: '/etc',
    prefix = '/usr/local'
    bindir = prefix + '/bin'
    libdir = prefix + '/lib'

I only do it because I don't want to bikeshed, and we shall never break free 
of autotools.

Your implementation seems very reasonable. I wish we could actually use 
Pathname objects instead of strings, but the file resources don't actually 
support pathnames (due to some string munging deep inside).
--
~j

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail