On 18 Feb 2011, at 12:04 PM, Markus Roberts wrote: >> Heh, right. I was trying to think of a clean way to give types a way to say, >> "autorequire the first of these dependencies that's found in the catalog, >> and ignore the rest". Adding an autorequirefirst method would do it in a >> backwards-compatible way, but that feels icky. > > Can you explain what feels icky about it? It seems like a legitimate (and > not particularly open-ended) extension of the api. If there were risk that > we'd be opening the door to later adding "autorequireallbutfirst" and > "autorequirethird" and such could see objecting strongly (heck, I'd be > objecting strongly myself) but in this case it seems like a semantically > sound addition that isn't likely to get out of hand and could plausibly be > useful elsewhere.
Maybe it's not really so icky. I wanted something that treated autorequires in more unified fashion, and was trying to think of a way to push information down into the type and/or yield items selectively from the autorequire blocks. But even if I came up with something it would almost certainly break the existing API. Shall I code up a weather-balloon patch for autorequirefirst? -- Ian Ward Comfort <icomf...@stanford.edu> Systems Team Lead, Academic Computing Services, Stanford University -- 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 puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
