Hi Luke, On Sun, 9 Nov 2008 23:16:03 -0600 Luke Kanies <[EMAIL PROTECTED]> wrote:
> [...] > > I did some more research in redmine and found #428 (Deletion should > > invert sort order) which seems to be very related to what i am > > after. I'm thinking about some general model for dependency > > handling and will post again in a new therad if i'm able to come up > > with something usable... > > It's a nice small patch; I'll have to help you get tests for it > before we consider applying it, but that shouldn't be too hard. > > I've got a couple of issues with it, though. The 'Type' class > already has a 'deleting?' method you can use to determine whether a > resource is being deleted -- currently it has the same behaviour > you're using, but it allows a resource type to override what deletion > means. This is useful for things like package purging -- it's a form > of deletion that doesn't use :absent. I know that and i'm not using this mechanism by purpose. The problem is that there are resources like exec which are not deletable at all. At first I simply ignored that fact and promptly ran into problems with exec inheriting a "below"-metaparam from an enclosing define and producing dependency cycles. Execs are not deletable and therefore we must respect that fact and throw errors if an attempt is made to assign above/below metaparams. The easiest way to do this is just to check for the ensure attribute. If it's not there we have a problem. If some type for some reason behaves completely different from the built-in ones, it is sort of likely that the above/below metaparams will not work properly for that one too. Because of this i think that it is safest to stick with the ensure attribute. > Also, what's with setting 'self.class.direction = (ens > == :absent ? :out : :in)'? That sets a class instance variable, > which means it will affect every above/below parameter, which can't > be what you mean. I think the only way to get the behaviour you > want I am fully aware of the fact that direction is a class instance variable but puppet does not multithread and thus it was the way of least resistance... Not the cleanest one though. > is to do some refactoring -- maybe use an instance-level 'direction' > method that normally just returns the class's direction and then > override the direction instance method in theseparams (preferable), > or refactor the 'direction' method to accept the ensure value as an > argument. OK, tried this in two new branches: refactor/master/type-direction feature/refactor-type-direction/vertdep Lorenz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
