Hi everyone-

At my current $job, the Perl code is organized into a handful of cpan- style distros. We use Module::Build to build each distro, and then use CPAN.pm to orchestrate the deployment of the application from a local CPAN repository. This all works like a charm.

But there is some debate about whether the MANIFEST and other metafiles should be put in the source code repository. My gut feeling is that MANIFEST is a generated file, therefore it does not go in the repository. Instead, the MANIFEST.SKIP file should be carefully crafted to ensure that the MANIFEST is correct. However, this raises a question: How do you ensure that *unexpected* cruft files don't end up in the MANIFEST?

My colleagues prefer to have the MANIFEST file in the repository so they can run distcheck to see what's been added or removed before committing some work. And then they manually edit MANIFEST or just run "./Build manifest" whenever MANIFEST gets out of sync. But we frequently forget to do this and it results in build failures in our continuous integration system.

In my own distros (Perl-Critic), non of the metafiles are in the repository. I only worry about the MANIFEST when I'm about to actually make a dist. We have Module::Build wired up so that the test target depends on the manifest target. The implication is that we would always run tests before making a dist. And only then do I really look inside the MANIFEST. If something seems amiss, then I add a line to MANIFEST.SKIP or do whatever is necessary at that point. I don't run continuous integration on Perl-Critic, but I feel this has worked well. At least I'm never bothered with spurious warnings about my MANIFEST being out of sync.

So what are the best practices for managing distro metafiles (MANIFEST in particular)?

Jeffrey Thalhammer
Imaginative Software Systems
vcard: http://www.imaginative-software.com/contact/jeff.vcf




Reply via email to