[chef-dev] Re: local file copy resource?

[Jesse Campbell < >]

I think I'd like to see consistency with the Template resource, using
a "source" option to specify a string filename.

I'm not exactly an expert at inheritance and composition in Ruby, but
maybe someone on here is?

Could we have a simple file resource that depending on specified
options it merges in partial classes adding required functionality?
Specify a  "source" option, it merges in the necessary file copy partial class
Specify a "template_source" option it merges in the necessary
templating partial class
Specify a "remote" option it merges a partial class with the ability
to fetch things remotely



On Sat, Dec 8, 2012 at 6:46 PM, Noah Kantrowitz 
<
 >
 wrote:
>
> On Dec 8, 2012, at 3:41 PM, Jesse Campbell wrote:
>
>> Looking at CHEF 1716 and CHEF-3676, I'm trying to figure out the best
>> way to implement local file copies.
>>
>> My thoughts:
>> - The File resource is very simple, and that is a good thing, don't
>> want to over load it doing too many things
>> - CookbookFile is specific to installing files from a cookbook, but is
>> almost identical to a local file copy. Adding a "local" option as for
>> 1716 doesn't make sense, simply based on the naming
>>
>> Here's a commit that adds the local option and would close 1716:
>> https://github.com/jcam/chef/commit/f0df80d0aac1cced64dc3d6d8cd064968dac473b
>>
>>
>> Here's Dan DeLeo's comments:
>>
>> cookbook_file feels a bit wrong, since we've scoped it to have the
>> functionality of pulling down files from the files/ section of a
>> cookbook.
>>
>> Putting it directly in the file resource also seems wrong, since it
>> doesn't currently have a concept of a source where the file comes
>> from.
>>
>> This leaves two options I can think of:
>>
>> 1. Add a local option to remote_file. This seems weird, since it's not
>> really remote, but it fits with the idea of pulling a file from one
>> place and putting it somewhere on the local system, just in this case
>> that somewhere happens to be a file system available to the local box.
>>
>> 2. Add a local_file resource and provider. This is the best conceptual
>> fit, and it shouldn't be too bad to share functionality from other
>> resources and providers via inheritance and composition. An argument
>> against is that you're creating "resource sprawl".
>
> How about 3. augment file so that #content can be a block returning a Ruby 
> file object (or string) so you could do
>
> file "foo" do
>   owner "whatever"
>   content { ::File.new("other") }
> end
>
> --Noah
>