Bug #82380 for Dist-Zilla: auto prereq detection failed to detect prereq in my distribution File::Util

On 2013-01-03 13:40:28, RJBS wrote: Show quoted text
I see, by looking at your git repository. Your only use of Exception::Reporter is in an __END__ section, which is not considered code, and not scanned. It is only loaded as code via string eval at runtime by the AutoLoader module. AutoPrereqs is not going to detect this unless you or someone else writes a scanner plugin for Perl::PrereqScanner that notices the use of AutoLoader and goes back to scan the __END__. -- rjbs

On Thu Jan 03 13:50:46 2013, TOMMY wrote: Show quoted text
Yes. Code that you've hidden in an __END__ section. The perl compiler stops reading a file entirely at __END__. This is documented. Therefore, so far as perl is concerned, it is not code. The AutoLoader module violates this assumption. It evals a string that, so far as perl knows, it could have got from -anywhere-. The simple answer here would be "stop using AutoLoader because AutoLoader is crazy". But since __END__ sections are -never- -touched- by the perl compiler itself, and this is -documented-, the fact that your failure to explicitly tell dzil that you have dependency that don't exist in normal code is your failure, not dzil's. CPAN testers are merely pointing out that there is a problem, they don't have an opinion to disagree with. Please fix the problem at its root - in your module.

On 2013-01-03 19:07:00, TOMMY wrote: Show quoted text
The documentation for AutoPrereqs says: Show quoted text
In other words: it might not find everything, and if you want to know how it looks, go check out Perl::PrereqScanner. In the end, that analyzes your document with PPI, which treats the contents of __DATA__ and __END__ as opaque blobs. As I said, one could write a plugin to make it notice the use of AutoLoader and rescan those sections, but it doesn't do that by default, because those sections are not considered code in Perl. You're just using a bolt-on that evaluates them (or the files built from them) later. Show quoted text
AutoPrereqs and Perl::PrereqScanner are functioning as intended and as documented. The tutorial is talking about them in a very limited circumstance: the tutorial's example. Now you know, too, how it works, and you can adjust your expectations accordingly. I will consider whether a few words could be added to that tutorial page to temper expectations without confusing the issue. Show quoted text
Your unpleasant attitude is not welcome here. I don't know what has upset you, and I'm sorry if it was your experience with my free software. I don't plan to sit around and suffer through this, though. -- rjbs

On Thu Jan 03 19:47:32 2013, RJBS wrote: Show quoted text
There's the ticket! Show quoted text
software. I don't plan to sit around and suffer through Show quoted text
OK, some perspective then... I took time out of my day to report a problem I was having with your software so that you could improve it. Instead I was basically told to go away and the words "crazy" and "failure" were used as descriptors for my own code. Nice, huh? That's called adding insult to injury. If you want to reject the bug, or dismiss the concern, it's possible to do it with class. For example, you could say "we acknowledge your concern but it isn't something we consider a defect and we will not be making an changes. Thank you for your bug report." It's called manners. If you want respect, be respectful. Don't tell people they are a failure or that they are crazy, mkay? And with that, thank you for Dist::Zilla. I like it, I use it, I think the tutorial documentation should be amended so other people using Dist::Zilla don't get bitten by the same gotcha. Have a nice day.

On Thu Jan 03 20:57:11 2013, TOMMY wrote: Show quoted text
I said AutoLoader is crazy. I did not say your code was crazy. I was implying that you might want to consider removing AutoLoader, since it involves more crazy than actual benefits in most cases - especially since it's not particularly well-encapsulated crazy and as a result causes knock on problems like the exact one you're experiencing. I said that you had failed to tell dzil about a prereq. Because you had. I didn't say your -code- was a failure. We all fail to configure things correctly sometimes. I was specifying the exact problem in the assumption that you, as a fellow programmer and intelligent human being, would then more easily be able to fix it. Neither of these things were insults. At no point did I say -you- were crazy, or that you -were- a failure, and I'm sorry that you read that implication into my words. Show quoted text
I'd love to see you propose a patch clarifying that; if you got bitten, then there'll probably be other people who expect the same thing and end up with the same problem - but I don't read that documentation the way you did, so I'm not sure how to rephrase it to fix that. Hopefully you can figure out a way to rephrase it that will do so, and hopefully you'll choose to contribute that rephrasing. However, the point where this discussion went off the rails was when your response to rjbs telling you exactly what the problem was was "My good friend, the CPAN testers would seem to differ with your assessment", rather than "oh, um, that's not how I read <this Show quoted text
maintainers tend to react badly to that sort of passive aggressive communication, and fundamentally I jumped into the conversation both to try and help you, and to try and avoid rjbs further experiencing your devaluing his contributions and knowledge by snide responses rather than constructive engagement. Hopefully that provides you with some perspective as to how you came across, and how to more successfully interact with other CPAN authors in future.