First cut at deployment module

[hartmans]

This is ready for @fxdgear to take a look at the general direction. There's still a lot of work to do. Provide way to find all the objects that should be deployed:

• Deployable is a new protocol for what deployable objects should have as an interface

• DeployableFinder is a plugin mechanism to find all the deployables

• MachineDeployableFinder finds all the machines.

• find_deployables is a top level interface to use the DeployableFinder mechanism.

[hartmans]

> are result_id's used anywhere that I'm not seeing?

Added the following comment above result_ids:

We want to make sure we return an object at most once, and make

# sure we never recurse into an object more than once. We cannot            
# have a set of results.  The main reason is that we cannot                 
# guarantee that all Deployables are hashable. The secondary                
# reason is that order may be desirable to preserve, although that          
# requires additional study. However id(obj) is hashable always,            
# so we can have a set of ids as a way to see if we have already            
# found an object.                                                          

> Does this need to subclass `Deployable` as well?

> I only ask cause we have a method `find` in both these classes. 1
> has a method signature of `(self)` and the other has a signature
> of `(self, stop_at)` and I'm wondering if these need to be the
> same.

Nope, DeployableFinder is a thing that finds Deployables. Think of it as a factory. Factories are not generally the same type as the thing they facture.

[hartmans]

"Nick" == Nick Lang @.***> writes: Nick> I noticed the method callback inside both find_callback Nick> and method_callback are eerily similar.

Do you think it's worth trying to make them reuse more code? If so, how? I'd probably pass in a success callback into the callback, which for a lisp person would be entirely natural, but might be stretching Python a bit.

The only differences being how the else is handled as well Nick> as on line 167 you set exception=exception.__context__ and Nick> on line 189 you set exception=exception.

What is the difference between using exception.__context__ and just exception?

They both should be exception.cause. We're effectively throwing away the outer InjectionFailed exception and getting closer to the root cause. The interesting thing in the outer exception will be what object we were working on (the deployable which we capture explicitly) and the dependency path (which we also capture). So it makes the failure report less verbose. It might even be desirable to actually discard an entire chain of InjectionFaileds until we get to something else.

[fxdgear]

Do you think it's worth trying to make them reuse more code? If so, how? I'd probably pass in a success callback into the callback, which for a lisp person would be entirely natural, but might be stretching Python a bit.

I'd argue for pragmatism at this point and in the future I would probably look for a way to reuse it a bit more if the need arises.

I was just curious. There were a couple differences which made it seem like this was purposeful as opposed to accidental. :)

[hartmans]

@fxdgear I have rebased and cleaned up the patches as well as completed both deployment and destroy. I think this is ready to merge, and am giving you a chance to go over it before we do that.