On Thu, Aug 29, 2013 at 12:40 PM, Nigel Kersten <[email protected]>wrote:
> > > > On Wed, Aug 28, 2013 at 11:36 AM, Brian Warsing <[email protected]>wrote: > >> CFPropertyList may only be required for OS X, but it is absolutely >> required. Most system resources on Mac OS X are abstracted as a binary >> plist (users, groups, services, packages, policy, configurations, etc) and >> the only way to reliably and sensibly work with this data is to have >> library that knows how to deal with the format. Relying on shell utils to >> read an write these resources on OS X is slow and untenable. >> >> I think there is more at stake here than just Facter and some some subset >> of its functionality. Now that RubyCocoa is dead, if PuppetLabs wishes to >> support Apple's platform, then CFPropertyList is the only game in town for >> Ruby projects. >> > > Brian is absolutely on the money here. You cannot effectively manage OS X > without plist parsing. Shelling out is slow, and parsing non-structured > output instead of plists is way too unpredictable. > > As someone who's spent way too much time writing in more than one language > with PyObjC, RubyCocoa, RubyObjC and MacRuby, I'm very strongly of the > opinion that we *have* to head towards supporting non-Ruby providers in > general, and ultimately we'll end up doing our more sophisticated work on > OS X with ObjC CoreFoundation tools. > > In the meantime we need robust property list parsing. > I definitely agree with this. At this point I think that bundling CFPropertyList at package time would be the best solution to achieve this. If there are improvements we can make to CFPropertyList we submit them upstream, which prevents Facter from being a 'proxy' for those changes. In addition we get the benefit of other fixes made in upstream. Another important point to note is that we use plist functionality inside of Puppet as well, but we implicitly rely on Facter to provide a plist library ( https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/nameservice/directoryservice.rb#L336). In reality a plist implementation (either plist or CFPropertyList) is a dependency of both Puppet and Facter, and vendoring a copy inside of Facter is probably one of the most painful ways to satisfy this dependency. My vote is to go with Mike's earlier comment that we unvendor, submit fixes to upstream, make it a proper dependency on OSX and either package CFPropertyList by itself or bundle it in during package generation. Are there any other solutions? -- Adrien Thebo | Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
