v0.1.12 fails tests for 5.14 and 5.16 about mozilla-publicsuffix HOT 8 CLOSED

The repository is a Dist::Zilla prebuild. Was your installation done from CPAN or directly from the repo?

from mozilla-publicsuffix.

The CPAN testers matrix also reports universal passage for perl v5.14 and v5.16:
http://www.cpantesters.org/distro/M/Mozilla-PublicSuffix.html#Mozilla-PublicSuffix-v0.1.12

from mozilla-publicsuffix.

From CPAN, not the repo. The patch is against whatever shows up on CPAN.

On Wed, Mar 6, 2013 at 1:31 PM, Richard Simões [email protected]:

The repository is a Dist::Zilla prebuild. Was your installation done from
CPAN or directly from the repo?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-14517333
.

from mozilla-publicsuffix.

Well, that's nice, but it fails for all of my builds of 5.14 and 5.16, but
NOT for 5.10 and 5.12, on all the platforms I test. Also, doesn't that
CPAN test matrix simply indicate the existence of a PASS for that platform,
as opposed the the LACK of existence of a FAIL? In my case, it fails,
reproducibly, and it can easily be corrected.

Are you interested in tracking down the root cause here? I suspect this
exposes a real problem with how the UTF-8 characters are handled, possibly
due to an interaction with one of it's dependencies.

In any case, the patch I provided is a slight improvement in how the data
is handled, but it's your call as to whether or not you want it.

On Wed, Mar 6, 2013 at 1:38 PM, Richard Simões [email protected]:

The CPAN testers matrix also reports universal passage for perl v5.14 and
v5.16:

http://www.cpantesters.org/distro/M/Mozilla-PublicSuffix.html#Mozilla-PublicSuffix-v0.1.12

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-14517725
.

from mozilla-publicsuffix.

I run perl v5.16.2 on all my boxes and can't reproduce the issue on any of them. I'd be interested in tracking down the root cause of issue and will post my installed versions of dependencies shortly.

from mozilla-publicsuffix.

OK I found it, and it was pretty subtle....

My build system does some things that are somewhat unusual, since I build
each CPAN module into it's own, private install tree, which allows me to do
some creative things like supporting multiple versions of CPAN modules
simultaneously, for multiple versions of perl. Part of that install
process involves discovering distro dependencies and then pre-building
them, for multiple platforms and multiple perl versions, BEFORE I build the
distro of interest. Although your distro, and most on CPAN, provide a
META.yml or META.json file, the MYMETA.* variants often contain dynamic
dependencies that are not present in the META.* files.

The dependency analysis code runs "Build.PL" in order to generate the
MYMETA.* files, and then afterwards, the "configure" step run it again, as
part of the normal build process. We've built over 2000 CPAN distros with
this infrastructure, and your is the first time I've run into a problem,
because what's unusual about your Build.PL is that is alters the source
code.

So... When it gets run the second time, Build.PL adds the %rules contents
a second time, and because you build the $rules string with no trailing
space... You end up with an odd number of hash entries. I added the
ability to turn off the auto-discovery step, and configured your distro to
use it, and everything worked fine.

Long story short, this exposed a very subtle issue with my build system
that I'll need to be on the look out for. There's nothing "wrong" with
what your doing in your distro, and I understand why you do it -- you are
giving the user the opportunity to update that file before the contents
gets "compiled" into the module itself.

Strictly speaking, you can close this issue and ignore it, if you like, but
I do think this is a minor issue for people who build your code manually.
If they run Build.PL twice, for example because the tests fail, and they
are "rebuilding" the module again, they will get burned by this, too, and
probably get very confused trying to figure out why.

I would suggest that you modify Build.PL to either be smart about editing
the file, so that the changes are made only once. That should be as simple
as a THIS patch, which matches the trailing paren outside the captured
match, which will only be true when the file has not been edited.

----snip----
diff -rc ../Mozilla-PublicSuffix-v0.1.12-orig/Build.PL ./Build.PL
*** ../Mozilla-PublicSuffix-v0.1.12-orig/Build.PL Wed Feb 20 12:34:43
2013
--- ./Build.PL Wed Mar 6 14:13:17 2013

*** 60,66 ****
} IO::File->new("effective_tld_names.dat")->getlines;

tie my @pm, "Tie::File", "lib/Mozilla/PublicSuffix.pm";
! for (@pm) { s/(my %rules = qw()/$1$rules/ and last }
untie @pm;

$builder->create_build_script;
--- 60,66 ----
} IO::File->new("effective_tld_names.dat")->getlines;

tie my @pm, "Tie::File", "lib/Mozilla/PublicSuffix.pm";
! for (@pm) { s/(my %rules = qw())/$1$rules)/ and last }
untie @pm;

$builder->create_build_script;
----snip----

On Wed, Mar 6, 2013 at 2:00 PM, Richard Simões [email protected]:

I run perl v5.16.2 on all my boxes and can't reproduce the issue on any of
them. I'd be interested in tracking down the root cause of issue and will
post my installed versions of dependencies shortly.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-14518990
.

from mozilla-publicsuffix.

Patched and released: 358dc79

from mozilla-publicsuffix.

Thanks!!

On Wed, Mar 6, 2013 at 4:55 PM, Richard Simões [email protected]:

Patched and released: 358dc79358dc79

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-14528658
.

from mozilla-publicsuffix.