If the main module has a companion pod file with the same basename, that pod file will be used in preference to the main module file itself as the source of the pod for the readme. This only affects the default and has no effect if the source_filename option is specified explicitly in the config.
- If you pruned away the README(.*) file before it could be populated with content, you'd get a fatal error like " Can't call method "name" on an undefined value at ...". Now we detect this and throw a more helpful (but still fatal) error suggesting you check your PruneFiles config. RT #97976. (Dave Rolsky)
…we can munge it
…r than re-munging the destination file
- Module now works with both Dist::Zilla version 5.X and up (which hanldes file encodings) and Dist::Zilla version 4.X and below (with no special handling of file encodings at all). This is a potential regression for users of Dist::Zilla 4.X, since previously this module made some poor attempts at handling encoding. If you need correct handling of file encodings, you should upgrade Dist::Zilla to version 5.
…odweaver_bad' into experimental Conflicts: lib/Dist/Zilla/Plugin/ReadmeAnyFromPod.pm
Now skeletal dist files are created in the file gathering phase and edited in the file munging stage; root files are created in AfterBuild. The file pruning operation is now detrimental as it would remove the file that we had just added. Use of proper phases now means that other plugins that care about the list of files produced will find out about these files in time. README is generated via the file gathering phase, so it always exists by the time we need to fill in the file's content.