| Subject: | pod detection is problematic when after __DATA__ |
from #toolchain, 2016-07-21 - check logs as there was more discussion that followed this bit...
00:36 < jberger> ether (et al): Module::Metadata can't read pod after __END__?
00:39 < jberger> that certainly is a nuisance
00:43 < leont> I never saw that, are you sure?
00:44 < jberger> I just had troubles with App::MBT generating a package (one I just converted) which had code -> __DATA__ -> data -> __END__ -> pod
00:44 < jberger> and it didn't work
00:45 < jberger> so I had to restructure to code ->pod -> __DATA__ -> data
00:45 < jberger> which worked fine
00:46 < jberger> https://metacpan.org/source/ETHER/Module-Metadata-1.000027/lib/Module/Metadata.pm#L564
00:46 <+dipsy> [ lib/Module/Metadata.pm - metacpan.org ]
00:46 < leont> Well, I can easily imagine how __DATA__ is a problem
00:48 < leont> As far as I remember, perldoc doesn't handle the former order very well either, but I may be mistaken
00:50 < jberger> well clearly Module::Metadata doesn't handle it given the link I posted
00:50 < jberger> perldoc never gave any troubles
00:51 < jberger> I personally like keeping the __DATA__ section closer to the code as it is more related (IMO) than the doc
00:53 < jberger> then again, not too many modules (outside of the mojolicious world) use __DATA__ to embed stuff, I don't think
00:53 < jberger> scripts sure, but modules, I don't see it too often
00:54 < jberger> oh! even worse: https://metacpan.org/source/ETHER/Module-Metadata-1.000027/lib/Module/Metadata.pm#L574
00:54 <+dipsy> [ lib/Module/Metadata.pm - metacpan.org ]
00:55 < jberger> it doubly hates my arrangement
00:56 < leont> Everything works fine for me unless __DATA__ is involved
00:59 < jberger> hmmm, ok I guess I can see how the __END__ handling doesn't prevent pod detection
01:00 < jberger> still the __DATA__ behavior is rather unexpected
01:11 < jberger> or maybe I'm wrong
01:12 < jberger> I thought __DATA__ section stopped at __END__
01:12 < jberger> but it isn't actually documented as such and a quick test proves that wrong
07:26 < xdg> jberger, I suspect that M::M gives up at __DATA__ because there is no defined end
10:03 <@ether> thanks for the reminder, I need to release MM 1.000032 from trial
10:04 <@ether> but yeah, __DATA__, then __END__, then pod is problematic all over.
10:04 <@ether> podweaver doesn't find pod there either, which means it's a more general __DATA__ problem I suspect.
10:05 < leont> I recently had an issue with pod inside __DATA__ being rendered by perldoc, but I forgot the details
10:08 < xdg> __DATA__ really needs to be treated as EOF
10:23 <@ether> MMD should do what the perl parser should do. If perl can find pod after __DATA__ and end, then MMD should as well
10:23 <@ether> likewise if the <DATA> stream begins at __DATA__ and ends at __END__ rather than eof, then MMD should keep looking for an __END__