I see, thanks Adrien -- the picture is coming into focus for me. So, the initial concern regarding the method collision aside, the major obstacle is vending code that requires periodic patching, which in turn demands a bunch of awkward code management practices.
In that case, could you simplify by including the gem (the whole thing, unmodified) and then use inheritance or a monkey patch created in a separate file to correct the namespace issue? That could create a manageable bridge between the two projects and allow the CFPropertyList to be updated independently of the core Facter code. On Wednesday, 28 August 2013 12:39:12 UTC-7, Adrien Thebo wrote: > > On Wed, Aug 28, 2013 at 12:36 PM, Adrien Thebo > <[email protected]<javascript:> > > wrote: > >> On Wed, Aug 28, 2013 at 12:33 PM, Brian Warsing >> <[email protected]<javascript:> >> > wrote: >> >>> Can you clarify: PuppetLabs patches the CFPropertyList gem before >>> vending it? >>> >> >> We have a pull request targeted at Facter that handles string encoding >> against CFPropertyList (https://github.com/puppetlabs/facter/pull/513); >> for cases like this if we're going to accept that change _and_ get it >> upstream, we would probably have to handle the submission against upstream >> ourselves. >> > > Wait, sorry, the question was if we're currently patching CFPropertyList. > The answer is yes, we have to change the namespacing to avoid potential > collisions, > https://github.com/puppetlabs/facter/blob/master/lib/facter/util/cfpropertylist/lib/rbCFPropertyList.rb#L45 > for > example. > -- > 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.
