[Rake-devel] Should unsuccessful File Tasks delete their target
rake-devel at rubyforge.org
rake-devel at rubyforge.org
Thu Nov 27 23:14:49 EST 2003
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
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. :)
> (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)
More information about the Rake-devel