FYI: I've been working on some very bizarre test suite failures in DBIx-Class, built using cpan2efs, and I've found a MAJOR FLAW in the assumptions I have made about using META.yml files.
This is a case where META.yml will *never* have the right dependency information, but yet MYMETA.yml will. Now, this may be 100% academic, because I don't think anyone else is using cpan2efs yet (or still -- Jerry?), but this is a case where not only does it miss an important dependency, you don't find out about it until something much further downstream depends on it and breaks. I'm going to rework efs_minicpan_extract to extract (or regenerate) MYMETA.yml instead of (or possibly in addition to) META.yml files. Then, cpan2efs will prefer the MYMETA.yml files over META.yml when extracting dependencies. ---------- Forwarded message ---------- From: Phillip Moore <[email protected]> Date: Wed, Oct 26, 2011 at 2:14 PM Subject: Re: [rt.cpan.org #71928] t/53lean_startup.t: Can't locate Tie/ExtraHash.pm To: [email protected] I have an answer for why noone else has seen this yet.... I'm working on trying to reproduce the OTHER problem I reported yesterday, and the first thing I noticed was that t/53lean_startup.t was passing, when I was expecting it to fail. Huh? Well, I hacked base.pm in the standalone test setup I just built, and when t/53lean_projects.t runs, base.pm NEVER SEES Tie::ExtraHash passed to it. Well, if you look inside clean.pm, it's clear why. Tie::Hash and Tie::ExtraHash are only used if B::Hooks::EndOfScope is NOT installed. If it IS installed, then it is used, and the code that causes this problem is not called. My working test case was simply a build of perl5.14.2 along with ALL of the dependencies my app has, installed as a bundle using cpanp. Somehow, cpanp figured out that namespace::clean 021 requires B::Hooks::EndOfScope, but the META.yml file for namespace::clean doesn't list this at all. cpanp figures this out when by parsing the output of Makefile.PL (or possibly using MYMETA.yml? have to go look...), but the build system in the failing case is very different -- it is driven entirely by metadata found in META.yml files, so when I installed namespace::clean, it was NOT built and tested against B::Hooks::EndOfScope. So..... In this case, the reason noone else is seeing it is that I have made the mistake of depending on META.yml files having correct dependency information, and when they information is missing, I depend on the tests failing, so I can address the missing ones. This is an edge case, where the Makefile.PL tries to dynamically figure out what can and can not be depended on, and the result is that the META.yml file included with it has a PARTIAL but not a COMPLETE list of dependencies. Oddly, if you run "perl Makefile.PL", and let MYMETA.yml get generated, that correctly lists the B::Hooks::EndOfScope dependency as "required". However, if you then run "make manifest dist" to regenerate the META.yml file, it says nothing about it. It looks like I need to change my build system to prefer MYMETA.yml over META.yml, since I can recreate these when they are missing (people are STILL uploading stuff to CPAN with no META.yml files). There may or may be a way to change namespace-clean's Makefile.PL to get that dependency listed correctly in the META.yml file, but regardless, lots of other modules will have similar issues, so I need to code a solution into my build system. I think it's safe to say that you can close this ticket, although I suppose that since namespace::clean CAN be installed without B::Hooks::EndOfScope and work fine, and since DBIx::Class doesn't depend on it, it IS possible that someone will see this, but very unlikely. On Wed, Oct 26, 2011 at 1:16 PM, Peter Rabbitson via RT < [email protected]> wrote: > <URL: https://rt.cpan.org/Ticket/Display.html?id=71928 > > > On Wed, Oct 26, 2011 at 01:08:07PM -0400, Phillip Moore via RT wrote: > > Queue: DBIx-Class > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=71928 > > > > > I've found the root cause of this, and I'm very curious why noone else is > seeing this error yet. > > > > Obviously, nothing in DBIx-Class refers to Tie::ExtraHash. That > dependency actually comes > > from namespace::clean, which is used by DBIx::Class::Carp. In > namespace::clean, the "right > > thing" is done to use Tie::ExtraHash as a base class: > > > > use Tie::Hash; > > use base 'Tie::ExtraHash'; > > > > This works because base->import does the following: > > > > eval "require $base"; > > die $@ if $@ && $@ !~ /^Can't locate .*? at \(eval/; > > > > However, in t/53lean_startup.t, because the require method is wrapped in > the first BEGIN > > block, the error that's thrown is NOT "at (eval)" it is "at > t/53lean_startup.t", the regexp fails to > > match, and base->import re-throws the error. > > > > I've reduced the problem to a very simple test case, which fails for > every perl I've tried, on > > every platform: > > > > BEGIN { > > *CORE::GLOBAL::require = sub { > > CORE::require($_[0]); > > }; > > } > > > > use Tie::Hash; > > use base 'Tie::ExtraHash'; > > > > Fuck you base.pm. Ok 2 things here: > > 1) There was some work on this test done in the DBIC repo. Please checkout > current master[1] and see if the issue has been fixed (the require() > override is much much cleverer now) > > 2) Since someone *else* may fuck this up in weird and unknown ways, I am > thinking to ship a version of n::c that sets @ISA instead of mucking with > use base (given how n::c is a pretty central thing these days). I do not > know if this is warranted yet, will ponder with interested parties. > > Thank you so very much for tracking this down, I am just as dumbfounded as > you on why nobody else experiences this... > > Cheers > > >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
