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

[Blake Irvin < >]

Thanks everybody for the feedback.

Maybe the question I really need to ask is, "does anyone *not* think we should move towards attribute-driven pathing?  I want to get a feel for community leaning before I put more effort into this cookbook and refactoring others/submitting pull requests, etc.

Blake

On Tue, Sep 17, 2013 at 5:01 PM, Joseph Holsten < " target="_blank"> > wrote:

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