There's no reason to include large, independently maintained modules like Pod::Simple in the parrot CVS tree and tarball. It just turns into a maintenance nightmare, should we ever start modifying these things. [...] I don't understand why you are insisting on including these things.
One reason might be reducing uncertainty. Including modules otherwise available from CPAN lets us control the versions used for parrot testing. We've already seen bugs resulting from using one version of perl rather than another. They are a pain to track down. Will myconfig start reporting on module version numbers too? Including modules insulates the parrot distribution from the vagaries of CPAN, and the enormously greater vagaries of peoples' local module installations. I can test parrot against any of my perl installs, without worrying about what is or isn't installed in them. I wonder how many potential testers we might lose if testing becomes an involved, site modifying exercise, rather than the current simple one? As you point out, these modules are not there to be edited. In a sense, they are there to prevent others from editing them, and thus affecting our users, without our being able to test them with the distribution first. Bundling modules when delivering software to a machine one doesn't control is actually quite common. Though admittedly something other languages (eg Tcl) have focused more on (and are better at;). The determinism seems perhaps worth the bloat. It's quite localize bloat after all. Mitchell (Though I certainly sympathize with the desire to scrub some of the accumulated cruft out the distribution... :)
