On Tue, Aug 10, 2010 at 10:14:04AM -0700, David E. Wheeler wrote: > On Aug 10, 2010, at 4:23 AM, Michael G Schwern wrote: > > > I updated Dist::Zilla, that usually fixes things, and I got a face full of > > Moose poop. The sort of stack trace that obscures the real problem. > > Picking > > through that, turns out it wants Dist::Zilla::Plugin::ModuleBuild::XSOrPP. > > > > I install that and try again... another face full of poop. This time its > > Dist::Zilla::Plugin::InstallGuide. > > > > Pooped on again, now it wants Dist::Zilla::Plugin::SurgicalPodWeaver. This > > one blows up in tests. I cannot build DateTime. This is a royal PITA. > > It sure seems like dzil, if not used properly, can significantly raise the > barrier to contribution for a project, even if it does optimize things for > the core developers. > > Just chatted with RJBS about this. He said: > > > My line has always been that of COURSE it does. It is to optimize the > > existing developers' time, not to lower general barrier to becoming a > > developer. > > > > Other people may claim that it doesn't. > > ... > > > you can use DZ in ways that do nothing to change the barrier to entry > > > > i.e., only for release management and VCS integration, or other such > > configurations > > I think that this is especially important for widely-used modules, > such as DateTime, that require a build process to test (that is, you > can't just run `prove -l t`. > > So perhaps it'd be helpful to check in the Build.PL, even though it's > generated, so that the barrier to contribution isn't so high.
The Git::CommitBuild plugin can help: http://search.cpan.org/perldoc?Dist::Zilla::Plugin::Git::CommitBuild "Once the build is done, this plugin will commit the results of the build to a branch that is completely separate from your regular code branches (i.e. with a different root commit). This potentially makes your repository more useful to those who may not have Dist::Zilla and all of its dependencies installed." Tim.