Daniel, I *think* I get what you're saying, but how would you translate this to something that needs to see if an entry in a file is synchronized?
Yes, I know that I could possibly use parsed file, but it didn't work out of the box the way I needed and it was faster to start from scratch than try to override parsed file correctly. An example of the following would be most welcome: - Updating entries in a file without using parsed file - Calling a command based on some random event (which is what package seems to do) Something that follows the flow of execution through the type and provider would be excellent. I see a lot of people noting how "easy" it is, but most that I see aren't deviating too far from the norm and I don't see a lot of explanation as to "why" you're doing what you're doing. Thanks! Trevor On Mon, Mar 7, 2011 at 4:56 PM, Daniel Pittman <dan...@puppetlabs.com> wrote: > On Mon, Mar 7, 2011 at 13:05, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > >> So, I have this working, but I'm not quite sure why I needed to do it this >> way. >> I took a look at the exec:returns property and the associated 'sync' define. > > This is, for reference, a bad model to build new types off; like file, > it predates a bunch of improvements in the code and we are only now > able to find time to rework it into something sensible. > >> I was getting an error about returning an invalid event and I wasn't >> sure what type of event I was supposed to return in sync. >> >> I noticed that exec is returning :executed_event but I don't see any >> other mention of this in any code anywhere. >> >> So, likewise, I just stuck a random unique :some_var in my sync method >> as the return value. >> >> But...why? > > So, like Stefan says, these are a theoretical future thing where we > extend subscribe/notify to support more than just a single value per > resource. This makes sense in a bunch of places, but that little bit > of code is a tiny legacy of the same, which isn't really used. > > Just return 'nil' for now, and ignore it. Er, and generally, don't > write a sync method if you can possibly avoid it. If you want to take > a template for how to build these things so your life doesn't suck in > 2.7, copy the package type and provider model. That is much more > likely to be stable over the longer term. :) > > Daniel > -- > ⎋ Puppet Labs Developer – http://puppetlabs.com > ✉ Daniel Pittman <dan...@puppetlabs.com> > ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 > ♲ Made with 100 percent post-consumer electrons > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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.
