[Rake-devel] Should unsuccessful File Tasks delete their target file?

[rake-devel at rubyforge.org]

On Nov 27, 2003, at 9:35 PM, rake-devel at rubyforge.org wrote:

> I've been going through the backlog of requests and suggestions and 
> came across this one from Chris ...
> Chris Thomas wrote:
>
>> 4. FileTask needs to delete the target when an exception is raised 
>> during execute. Otherwise, the next rake invocation may find a 
>> partially-constructed target and not see the need to rebuild it. I'm 
>> not sure if FileTask is the right place for this, perhaps it should 
>> be the subclass's responsibility.
>
> This seems like a reasonable request, and I already have the unit test 
> for it (see testtasks.rb, the FileTaskTest class, last test method). 
> However, unconditionally deleting a file on failure may be a bit 
> drastic and I would like some feedback before I implement it.
>
> (1) What's a realistic scenario where it would be desired.

Here's the scenario leading to the request: I'm building a Mac OS X 
"file package," a directory presented to the user as a file. In this 
case, all of the files are strongly interrelated, and it makes sense to 
generate them all in the same task. Thus, the target is a directory 
containing files dynamically created by the task. Say an exception 
occurs partway into the task, before all of the files have been created 
or copied into the directory. On the next rake run, the directory's 
mtime appears to be up to date, but the contents of the directory are 
actually only partially constructed. This is very fun to debug. :)

One might consider a directory implemented as a FileTask an unusual 
case. However, this could also happen in any case where a FileTask 
generates the file and does not itself delete the file when an 
exception occurs. Consider a compiler that, on encountering an error, 
leaves a half-generated executable file. Most compilers and other major 
tools clean up after themselves, so this isn't an issue with, say, GCC. 
But it isn't clear that you want every ad-hoc FileTask to have that 
responsibility.

The question as I see it is: should every FileTask subclass which 
incrementally generates the target be required to catch exceptions and 
delete the partially generated target (considering that extreme 
debugging fun may occur if the target is not deleted)? The same 
question applies to any opt-in scheme implemented in FileTask itself 
(task.delete_target_on_exception = true).

> (2) Is there a realistic scenario where deleting the target file would 
> not be desired?

Perhaps if I had a FileTask for a directory containing files that are 
themselves individually represented by FileTasks, and the individual 
FileTasks are expensive to execute. I can imagine this happening for 
complicated file packages, although (a) you may still be in trouble if 
you have a partially constructed directory and (b) at that level of 
complexity it's probably wise to consider implementing an OS X-specific 
FilePackageTask or something...

Anyway, that's my story. Counterpoint and other feedback welcome. :)

Chris

> (3) What defines success and failure.  I'm strongly leaning toward an 
> exception thrown during a task action is considered failure.  Any 
> other thoughts.
>
> In general ...
> The code base is beginning to stabilize for 0.3.0.  FileLists now use 
> the ant-like include/exclude nomenclature.  I've broken PackageTask 
> from GemPackageTask so that packaging doesn't depend upon the presence 
> of RubyGems.  Documentation is fairly up to date (I've got some 
> catchup to do in the package area).
>
> I try to keep CVS up to date with the latest.
>
> Thanks to everyone for their suggestions and comments.
>
> -- 
> -- Jim Weirich       jweirich at one.net      http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)