On Mon, 2011-01-31 at 00:19 -0800, Luke Kanies wrote: > Hi all, > > I think there are a few classes or subsystems in Puppet that could, > and maybe should, be extracted into separate projects so they can be > more widely used; at worst, they could at least be shared by our other > projects. I'd love to be able to pull functional bits out of Puppet > and use them elsewhere -- e.g., I'd love to have mcollective, Puppet, > PMT, and Facter all share the code that creates their applications.
It certainly makes sense... but... > I'm thinking of, at the least, our graphing stuff and the application > classes (plus the Interface classes I'm working on[1]). > > The problem with doing this, of course, is that it introduces that > external code as a dependency, which doesn't really work. > > I expect the only real choices are to list them as dependencies, or do > a kind of vendoring, like we're doing with Event::Loop and JSON. > > How do other projects solve this? Does anyone have any experience > doing so? My experience with some of my company projects is that it makes everything harder: * it's harder to submit patches that encompass more than one project. Developper have to split their patches, make sure they are queued and merged at the same time to all the projects. * it's harder for developper to setup a dev environment, if they have to manually fetch all deps. * it's harder for newcomer to understand how the bits they are interested in fits in the big scheme. * it's harder for maintainer to keep track of various dependencies versions to perform a release. * it's harder to isolate bugs, when you have to check all the possible versions of a given sub-system. * it's harder for various sub-system maintainer because they have to version everything. I don't think we ever found a good way to solve this problem. We tried git submodules, but there were too many caveats. So since we're a java shop, we finally ended using the full power of maven to manage all our dependencies/artifacts and try to impose a strict versioning of all our internal submodules (but still the problem is more complex than when we had only monolithic projects). This adds some overhead to the development and release process. In a non-maven world, Buildr is a really nice alternative. HTH, -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
