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

[Daniel DeLeo < >]

On Wednesday, December 12, 2012 at 10:03 AM, Zac Stevens wrote:

Jesse - thankyou for working on this.  Whatever form the solution takes, I'm sure I'll use it.

I wanted to add my 2 cents...

On Wed, Dec 12, 2012 at 4:48 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Tuesday, December 11, 2012 at 5:22 PM, Jesse Campbell wrote:

Okay, so what would you like to see? FileCopy provider for local file operations, and CookbookFile extends FileCopy? Where to put Bryan's move?

Happy to go about this differently, but a local option to cookbookfile seems backwards

I agree a local option to cookbook file isn't the right way to go. My favored options are either a file_copy resource and provider, or a local option to remote file.

I dislike the idea of a file_copy resource - I think it's because I parse it as an imperative (copy X to Y).  On the other hand, I see how it could be read declaratively (ensure Y has the same contents as X).  

Permitting a local file URI as remote_file's source (eg: source "file:///path/to/source/file") makes the name of the resource a little misleading, but otherwise fits the way I currently look at the file resources:

file - for asserting that files are absent, or present with contents inlined in the resource declaration.

cookbook_file - for asserting files exist, with contents from a file shipped with the cookbook

remote_file - for asserting that files exist, with contents coming from elsewhere

That said, I find it difficult to infer the conceptual model that results in three resources distinguished in those ways.  If there is one, I'd expect to find a matching trio of template resources - if not, it sure would be nice to unify the file resources in a future, major release.

Can you explain what you think the benefit is of unifying all the file resources? Would you keep template separate (why/why not)?

As I said in a previous email in this thread, I feel there's a benefit to having the implementation-specific resources (e.g., separate template vs. remote_file vs. cookbook_file, etc.), since they implicitly express where to look for the source file which I believe helps for code reading/debugging and also allows for more brevity. To me, this is a worthwhile pragmatic compromise whereby accepting some leak of implementation detail into the model makes using the model in everyday situations actually simpler.

That said, a few people have brought up contrary opinions, and I'd like to understand this. Is it just modeling purity, or do you imagine other tangible benefits?

-- 

Daniel DeLeo

 

Zac