You can clone with
task :default => ['dummy']
file 'dummy' do
Clearly this task fails. Yet rake does not restart it if you run it the second time.
Because you cannot trust the user using rake to write proper code it must be rake either deleting the file on exception or renaming it , eg appending '.failed'.
Running rake the second time should always show the same error, if possible.
Currently such a case silently ignores an error. That's behavior nice build systems should avoid.
I think you misunderstood how task dependencies work here.
You default task depends on "dummy". On the first run, there's no file "dummy" (because you don't specify a path, it does not mean that it's not a file, rake will use it's working directory) so the file task is called.
In it you actually create the file before raising the exception so the next time you call default the file is there and the file task condition is satisfied.
You cannot expect rake to make the arbitrary decision to delete/rename a file on error just because there is an error in the task's logic. File tasks might check for a file's existence and do something completely different, usage of relative path names (as in your case) would be equivalent to an 'rm -rf .' and I can think of all kinds of evil things to do with it.
So, no rake should not babysit the programmer by any means.
I'll babysit rubinius devs and send them patches then. I agree there are use cases for both. And probably you're right
You are right, and the fix is to write to a tmp file, then use an atomic move at the end