I agree with Corion here: I distribute MANIFEST.SKIP and think it's ok to distribute the /xt directory (or author-only tests). It just assures that if someone else wants to work on the module too, they've got everything that I would use if it were me working on it. It's easy enough to ensure that those ./xt tests only run if an environment variable is set, so at worst they're a little extra disk space, and at best they might help another contributor, bug-fixer, etc.

Dave

Comment on
Re^2: What are the files in a CPAN distribution?
Download CodeReplies are listed 'Best First'.

Most modules are no in some sort of reproducable VCS: svn or git, and most have some sort of preferred way of contributions (github).

If people want to work on a module/distribution, a git clone or svn copy will get you *all* files, including those that - I agree with tobyink here - are listed in .gitignore and MANIFEST.SKIP. I hope at least that the authors are sane enough to have these two in the repository anyway.

I do keep modules in public Git repos, and in the module's POD point to that repo. Nevertheless, when someone looks for a distribution, they look to CPAN, and I try to provide the complete dist there. Anyway, the good thing about Perl is that TIMTOWTDI. :)

We can not rely only on the source repository of the author to get the original source. First, too few authors advertise the place of that repository in their metadata. Then, the author may decide to make it private, or delete it completely. Look at what happened to Marcel Grunauer 200+ modules when he dropped his Github account in August 2011...

The only reliable archive is the CPAN. This is where the source must be.

This is why I hate tools that transform the original source : PodWeaver, Dist::Zilla::Plugin::ExtraTests...

I agree. Even if the tests are never run by someone else, they might still prove a valuable resource to another author. And if (somewhat unexpectedly cause my code is always perfect) bug reports start flooding in, it is always a good thing to have all existing tests for the distribution already deployed. It's much easier to ask a user to "just run this command(s) and post the output" than first having to haggle about how to send the test scripts and set up the test environment.

"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"