Install to Non-Default Dir

[NGT JAH]

Hello I had one small issue when using this cookbook.

I selected a directory to install to other than the default '/opt/lita' by doing this:

default[:lita][:install_dir]  = '/home/lita'
default[:lita][:log_dir]      = '/home/lita/logs'
default[:lita][:run_dir]      = '/home/lita/run'

For some reason everything works except that I end up with this one file that is incorrect.
[root@ngtrdev lita]# pwd
/etc/service/lita
[root@ngtrdev lita]# cat env/HOME
/opt/lita

I ended up just copy/pasting this section exactly how it was from 'attributes/init.rb' to my main(parent) cookbook's attributes file.

default['lita']['runit']['env'] = {
    'HOME' => node['lita']['install_dir'],
    'PATH' => [node['languages']['ruby']['bin_dir'],
               node['languages']['ruby']['gem_bin'],
               node['languages']['ruby']['ruby_dir']
    ].join(':')
}

Then Success
[root@ngtrdev lita]# cat env/HOME
/home/lita

I played around with it a bit and I suspect there is something I am not aware of that is happening when the non-default attributes files 'attributes/init.rb' is loaded.

I can see that when the node['lita']['runit']['env'] hash is passed to the 'runit_service' resource in 'recipes/init_service.rb' that the value is incorrect but I am just not quite sure why...

 {"HOME"=>"/opt/lita",
   "PATH"=>"/usr/local/rvm/rubies/ruby-2.2.3/bin:/usr/local/rvm/rubies/ruby-2.2.3/bin/gem:"}

-jah

[Harlan Barnes]

What you are experiencing is the (fairly common) issue of derived attributes. What you've done is correct given that the runit attributes section relies on them. I didn't notice it when I merged it, but I would guess the author of this feature was wanting to have sane defaults, but leave the runit_service resource's env option flexible enough to be overridden in a wrapper recipe (as you've done) or a role/environment/whatever. I'll look around and see if there are some patterns that would fit both needs. I seem to remember there was one that was starting to become popular, but I think it had drawbacks as well.

[Harlan Barnes]

This seems to be the best review of the issue that I found:

https://christinemdraper.wordpress.com/2014/10/06/avoiding-the-possible-pitfalls-of-derived-attributes/

I've updated the attribute for that value to be nil but it will set a default in ruby itself avoiding this problem. I think this accomplishes the fix for this issue but still let's people that need more complex environment settings to control that value. I tested this and it seems to work as expected in both cases.

If this doesn't work for you, let me know.