add options recursively from dependencies

[Yap Sok Ann]

Hi Kevin,

Currently, _handle_dependencies only takes into account the direct dependencies. I think it will be a great convenience if it can take care of all dependencies recursively.

On a related note, if 2 dependencies have the same option, the option will appear twice in the parent task. A more useful behavior is to consolidate all options from dependencies so that there is no duplicate.

Attached is a simple patch I come up with. It will cause infinite recursion if there are circular dependencies :)

Regards,
Yap

[Kevin Dangoor (dangoor)]

This seems like a good idea on the surface. But, I think the wrinkles make a it a bit more complicated.

For example, let's say that a task has an option called foo, but foo is not available as a command line option. But that task @needs another task which has an option 'foo'. So, the 'foo' option suddenly becomes available and options.foo will get overwritten by the command line option, even though options.foo is for two different tasks.

And does this do anything weird if there are distutils/setuptools commands in @needs? (There's already some unfortunate behavior with distutils commands and command line options, because you'll get an error if an option gets passed through that the distutils command knows nothing about.)

I'm guessing that if you wrote some unit tests you'd find some weird behavior as I'm describing. I could possibly take this as an option to cmd_opts (inherit=True, perhaps?), but I'd still like to see a unit test for it... they're not very hard to write if you look at the existing ones.

Perhaps a better approach would be to make it optional whether or not to inherit command line options and possibly to list the ones explicitly that you want. I just wouldn't want people's build/deployment scripts to start having weird behavior.