pause
pause copied to clipboard
andk
indexing of Package-Variant attempts to index a 'string' package
Re http://www.nntp.perl.org/group/perl.modules/2013/05/msg85885.html --
Is there any way we can make PAUSE not think that this code means it should attempt to index a 'string' package?
https://metacpan.org/source/ETHER/Package-Variant-1.001004/lib/Package/Variant.pm#L34
Can we use something like Module::Metadata to parse the .pm to extract 'package' keywords?
Does this fool Module::Metadata? If not, then either PAUSE should start to use M::M or at least it should use an equivalent regex.
In this particular case, looking for qr/$PACKAGE\s+$NAME(?:\s+$STRICT_VERSION)?\s*[;|{]/ or so ought to do it. I.e. find the trailing semicolon or brace opening.
David
The traditional way to avoid PAUSE's regex is to put a newline between the words "package" and "string".
You can also add a no_index entry for the string package in your META.json/yaml.
Ideally PAUSE gets better, but those are your accepted workarounds for now.
Thomas Sibley [email protected] writes:
The traditional way to avoid PAUSE's regex is to put a newline between the words "package" and "string".
You can also add a no_index entry for the string package in your META.json/yaml.
Ideally PAUSE gets better, but those are your accepted workarounds for now.
Don't forget: if the META file has the provides section it is honoured!
andreas
The package hiding trick does not really work here because Karen's problem comes from PAUSE finding what it thinks is a package name in an error message inside a string. The workaround would not be have the string '\s+package\h+\w' anywhere in your code, even as data. People are not going to avoid doing that because they don't expect PAUSE to look in data for code.
it appears it may be just a typo in PAUSE's regex. It already looks for end of line or the semicolon, as in @dagolden's suggested regex, but instead of also looking for an opening brace it looks for a closing brace (introduced in 786d9c9): https://github.com/andk/pause/blob/master/lib/PAUSE/pmfile.pm#L225
@karenetheridge's particular false negative should be fixed if that closing brace is flipped to an opening one.
The closing brace happens to be legal, but I would argue that {...; package foo} isn't likely to be a useful Perl construct, so it more likely to be a false positive.
We're in a twisty maze of heuristics here.
David
@karenetheridge I just took a look at Module::Metadata. It uses the same static analysis approach as PAUSE and its regex is broken in ways I don't think PAUSE is (doesn't parse multiple package statements on a single line, for example). To use it for PAUSE, it'd need to be brought up to parity. A unified set of heuristics for finding packages would be nice! (As long as the needs of PAUSE and Module::Metadata remain the ~same.)
I'm not convinced that PAUSE is de facto "right".
package Foo; package Bar; package Baz;
How likely is this to show up in actual code? Only Baz is operative.
I have no objections to reconsidering PAUSE's heuristics if we think we can make them better.
In this case, looking for "package NAME" followed by trailing semi or open brace, (or "package NAME VERSION") seems more likely to catch a "real" package declaration and not just any occurrence of 'package XXX' in the file
@dagolden I agree with you.
Multiple useful package statements on the same line are possible, but I'd guess unlikely except in automatically "minified" code:
package Foo; sub foo { print "foo" } package Bar; sub bar { print "bar" };
package main;
Foo->foo;
Bar->bar;
And even those have trailing semicolons. (note sure if Module::Metadata or PAUSE yet detect multiple package statements on a line in any case)
The semicolons don't matter. What I was noting is that Module::Metadata won't detect Bar in my example above (I tested it), but PAUSE will (or should, I didn't test but inspected regex and surrounding code). It's a matter of how the start of the regex is anchored in each.
I'm just noting a difference between Module::Metadata and current PAUSE, should the latter start using the former.
