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