Add DependencyFor attribute.

[ArkaHnat]

I added DependencyForAttribute as it would be good to be able to define dependencies also on dependent modules.

[thomhurst]

Heya @ArkadiuszHnat

I'm not sure I want to do something like this. I don't really understand the benefit of it, especially when we've already got the DependsOn attribute. What problem is it solving?

It also wouldn't work if a module came packaged up in a library. You'd no longer have control over it's definition so wouldn't be able to use this attribute.

[ArkaHnat]

In my opinion it incrases flexiblity. Nuke-build is using similar approach.

For example we can have modules hierarchy like this:

TopModule
   -->DepModule1
   --> DepModule2
   -->DepModule3

Then you can remove any of those modules without modification of TopModule.

Regarding packkaged modules. I'm not sure if I understand correctly but wouldn't we have similar situation with DependsOn if we will miss dependency?

[thomhurst]

But if a module depends on another, you must specify that attribute. The compiler will force you to via the analyzers. So even if packaged up, it's still forced to have that attribute on it.

Then you can remove any of those modules without modification of TopModule.

But that's the existing behaviour. DepModule1 says it Depends on TopModule. You can then delete DepModule1 and nothing needs to change.

[ArkaHnat]

We might not understand ourselves and probably talking about different cases. If you will look into ModularPipelines.Examples there is DependencyForReliantModule which is dependency for ReliantModule (really suprising;)). I can remove DependencyForReliantModule without need of modification of ReliantModule

[thomhurst]

@ArkaHnat honestly I just think this makes it more confusing. It makes sense for a module to declare what it depends on, so it knows not to start before others. But the other way round doesn't make sense, because a module doesn't need to know what depends on it in order to do anything.