You can clone with
HTTPS or Subversion.
It'd be really nice if when a task raised an uncaught exception, that data wasn't swallowed - I often feel like Rake is taunting me with its "run again with -t" - Rake tasks often are not trivial to run.
I've put up a gist of a monkeypatch that I'd cheerfully turn into a pull request if it'd be acceptable.
What do you mean by "Rake tasks often are not trivial to run"?
I don't think it would be useful in all cases to see the backtrace. Most frequently I have found -t is required to see the specific context of the error since the backtrace does not show which task is being executed. Perhaps ex.chain is sufficient.
I'll second @drbrain.
The non-triviality of tracing an error has all to do with how we structure our code and nothing with the basic task mechanics that rake offers.
Seeing the task chain is very helpful, seeing a stack trace less so especially for those not involved in actually implementing the offending code. So delegating detailed analysis (with -t) to a later point instead of polluting the log is what I call "polite"
You assume that everyone running rake tasks cares for the stack trace in case of failure which is most certainly not the case. And stack traces are very often misleading especially in any non trivial system.
Just like every other piece of software, rake tasks need proper structure: break up the tasks in as many file tasks and or dependencies you can to be able to isolate errors. Having the dependency chain allows you to rerun exactly the dependency that failed. Aim for task granularity that prevents you from wasting any time (as an aside if you ever need to parallelize - see MultiTask - execution then you're going to be in a very good position)
I've got a rake system with more than 7k lines of code and some tasks that need close to an hour to complete and it never takes me more than a minute to locate failures. Patching the tool to accomodate sloppy practices is a very bad smell to me.
When you write rake tasks as @damphyr describes they are much easier to diagnose and fix even when rake takes a long time to complete.
However, having some debugging information for a failed task would be useful even when the backtrace is not (as it might not be useful if you have small rake tasks).
Since the error report would show up on $stderr I wouldn't be polluting the log.
I think a hybrid approach like rubygems uses would be most useful where there are three types of output. For no arguments, a simple report is shown including the exception and task chain.
For --backtrace a rake backtrace is shown in addition to the above.
For --trace a full rake trace is performed in addition to the above.
If you would like to have the backtrace on at all times you can export RAKEOPT=--backtrace
I completely agree with a many-small-tasks approach. However, I have the misfortune that 80% of my Rake usage is on Rails, and the majority of useful Rails tasks depend on :environment, which is itself annoyingly long-running. File tasks are indeed excellent practice, but less useful when making modifications that aren't to a local filesystem.
Dividing --trace and --backtrace does sound like an excellent approach to me - I think the only place the distinction would be essential is in Rake::Application#display_error_message, although there may be other places I'm not aware of.
This is bugging me every time. Best example are Rails migrations:
Then tend to run long and/or have nasty side effect which make rerunning them a bit of a pain.
@drbrain Is it worth putting together a PR for splitting out --trace and --backtrace ? (i.e. in principle is it worthwhile enough to be likely merged?)
@nyarly that would be much appreciated
Actually: it looks like @grosser already did this: #109 - could we get that merged, then?
Backtrace option is merge with HEAD and will be in the next release. If you want backtrace by default, then put RAKEOPT=--backtrace in your environment.