On Wed, Aug 28, 2013 at 1:09 PM, Brian Warsing <[email protected]>wrote:
> 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. > By including the gem, do you mean adding the gem as a dependency and packaging it ourselves, or do you mean keeping the source embedded inside of Facter? If the latter, that doesn't really buy us anything. In order to have the pristine library in one source location and then 'vendor' it programmatically, we would have to do some seriously dark magic to relocate the CFPropertyList constants to Facter::Util::CFPropertyList and get rid of the top level CFPropertyList constant. In addition, if we're using monkey patches to add our own changes to CFPropertyList, the bytestring patch for example, that would mean more or less duplicating the monkey patched method in question, which doesn't have many advantages but gets a lot harder to maintain. Lastly, there's the low level problem of how upstream patches get copied in. Do we use git subtree merges? (I sincerely hope not.) Do we use diffs and patches? (Not much better.) My understanding is that any situation where Facter and CFPropertyList are going to reside in the same repo is going to be very painful. Moreover, doing so is going to make us de-facto maintainers of the library, which is a commitment that I don't think we should place on the Platform team. If we can separate the code bases and then bundle Facter and CFPropertyList at package time that'll alleviate some of the pain. But at that point, CFPropertyList would just be another dependency, and not a vendored library. -- 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.
