[prev in list] [next in list] [prev in thread] [next in thread] 

List:       puppet-dev
Subject:    [Puppet-dev] Failed dependency behavior
From:       luke () madstop ! com (Luke Kanies)
Date:       2006-07-05 23:36:40
Message-ID: 44AC4D08.3040102 () madstop ! com
[Download RAW message or body]

Scott Seago wrote:
> The other advantage of being able to return a type is that you can have
> a single autorequire block which can return an instance of a different
> type depending on circumstances. For example, a filesystem object may
> depend on a partition, a logical volume, or a raid array, but never more
> than one of these. A single autorequire block can determine which one to
> require and return that object.

Hmm.  Except it can't with the current implementation -- you have to 
specify the type of object you'll be autorequiring, and you're expected 
to just return a list of names.

I just checked the code, though, and if you returned objects, instead of 
just names, then you could ignore this type relationship.

 > [...]
> On the other hand, if the "missing dependency == error" case is a rare
> one, then perhaps the current situation is fine, since you can always
> throw an error explicitly from the autorequire block -- this is what I'm
> currently doing for the storage autorequires, since I'm returning types
> rather than strings.

It shouldn't be difficult to add options to the autorequire system. 
Just expand the class @autorequires hash to include options, in addition 
to the block, and then modify the instance method to handle those 
options appropriately.  Then you'd just call autorequire with those 
options in the method call:

   autorequire(:volume, :elsefail => true) do ... end

Rails does a ton of this.

-- 
Fallacies do not cease to be fallacies because they become fashions.
--G. K. Chesterton
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


[prev in list] [next in list] [prev in thread] [next in thread]