Hello,

I just got this FAIL report today from CPANTesters:


http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a630-0d8a02da96e1

As you can see, the prereq is correctly recognized by the toolchain
and loaded - it's even in the lengthy @INC list, BUT when executing the
test script it seems like @INC disappears somehow? Since I don't know
the details of your setup I have to assume something is broken.

Can you verify that it's not a problem with just my module? There's
no easy way to search the cpantesters database for all of your reports
so I can check to see if you've been sending bad FAILs or not. Can you
please test my module by hand to see if it really works? Thanks!

I suspect it's something to do with MSWin32 limitations, as I have
received several other FAILs in the past with the same symptoms as this
one. However, as I don't have access to a box now I can't quickly test
my theory out. I have sent an email to the list several weeks ago but
seems like everyone was busy :(

The subject was "Weird failures from smokers on MSWin32?"

Thanks again for your assistance with this and again, BIG THANKS for
running a smoker! :)

~Apocalypse

Search Discussions

  • Christian Walde at Mar 30, 2011 at 8:55 am

    On Wed, 30 Mar 2011 02:22:32 +0200, perl@0ne.us wrote:

    Hello,

    I just got this FAIL report today from CPANTesters:

    http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a630-0d8a02da96e1

    As you can see, the prereq is correctly recognized by the toolchain
    and loaded - it's even in the lengthy @INC list, BUT when executing the
    test script it seems like @INC disappears somehow? Since I don't know
    the details of your setup I have to assume something is broken.

    Can you verify that it's not a problem with just my module? There's
    no easy way to search the cpantesters database for all of your reports
    so I can check to see if you've been sending bad FAILs or not. Can you
    please test my module by hand to see if it really works? Thanks!

    I suspect it's something to do with MSWin32 limitations, as I have
    received several other FAILs in the past with the same symptoms as this
    one. However, as I don't have access to a box now I can't quickly test
    my theory out. I have sent an email to the list several weeks ago but
    seems like everyone was busy :(

    The subject was "Weird failures from smokers on MSWin32?"

    Thanks again for your assistance with this and again, BIG THANKS for
    running a smoker! :)

    ~Apocalypse
    I reproduced this case and it seems that this might actually be a Perl bug. Situation is as follows:

    My CPAN is still 1.9402 and configured to reuse_build_dir.

    This means that in order to run a test on a module, it will throw *all* the build dirs in ~/.cpan/build into $ENV{PERL5LIB}, which i understand is added to @INC by the perl executable itself. ( http://perldoc.perl.org/perlrun.html#ENVIRONMENT )

    Reproduction thus was relatively easy:

    Stop the smoker, run cpan, `look` at an affected dist, in my example Params::Classify and `make test`. In order to make the output more useful i added debug statements to CPAN.pm and gutted the test suite of Params::Classify, replacing it with a single test that tries to use the module and dumps environment and INC information. Here's the output:

    https://gist.github.com/893981

    Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a whole battery of directories in $ENV{PERL5LIB} ( https://gist.github.com/893981#L247 ) which the perl executable can obviously see, including the Params::Classify dir as the very first; since that's a Data::Dumper output of %ENV. However @INC remains unchanged by that. ( https://gist.github.com/893981#L579 )

    This seems to indicate to me that the perl executable itself is, for whatever reason, flat out ignoring the PERL5LIB and/or failing to inject it into @INC. Other possibilities include Module::Build messing things up or the Windows Perl executable exclusively having issues.

    I do not know how to further pursue this issue, but will happily provide any assistance needed in digging deeper into this.

    (And for now will try to at least follow up bugs FAIL reports with proper PASSes by periodically cleaning out /build and removing fails from my reports-sent.db.)

    --
    With regards,
    Christian Walde
  • Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 at Mar 30, 2011 at 10:34 am
  • Christian Walde at Mar 30, 2011 at 1:42 pm

    On Wed, 30 Mar 2011 10:54:57 +0200, Christian Walde wrote:
    On Wed, 30 Mar 2011 02:22:32 +0200, perl@0ne.us wrote:

    I just got this FAIL report today from CPANTesters:

    http://www.cpantesters.org/cpan/report/0ee8eb99-6c5d-1014-a630-0d8a02da96e1

    As you can see, the prereq is correctly recognized by the toolchain
    and loaded - it's even in the lengthy @INC list, BUT when executing the
    test script it seems like @INC disappears somehow? Since I don't know
    the details of your setup I have to assume something is broken.
    https://gist.github.com/893981

    Of note: The test ( https://gist.github.com/893981#L225 ) clearly has a whole battery of directories in $ENV{PERL5LIB} ( https://gist.github.com/893981#L247 ) which the perl executable can obviously see, including the Params::Classify dir as the very first; since that's a Data::Dumper output of %ENV. However @INC remains unchanged by that. ( https://gist.github.com/893981#L579 )

    This seems to indicate to me that the perl executable itself is, for whatever reason, flat out ignoring the PERL5LIB and/or failing to inject it into @INC. Other possibilities include Module::Build messing things up or the Windows Perl executable exclusively having issues.
    Thanks to Brian Raven i managed to condense this into a minimal test case script and collect behaviors across multiple platforms, so i could figure out that perl core was handling PERL5LIB badly on Windows 7 (ignoring env values despite being able to handle them). I've reported this issue here:

    http://rt.perl.org/rt3/Ticket/Display.html?id=87322

    As for the smoker, as Lars Dieckow suggests i'll just disable build_dir_reuse for now. It will slow the smoker down massively, but there's no quick fix for this. Maybe sometime in the future i'll build a build_dir_reuse function that can do the same job without increasing ENV vars massively.

    Thanks for all the feedback. :)

    --
    With regards,
    Christian Walde
  • Andreas J. Koenig at Mar 30, 2011 at 4:57 pm

    On Wed, 30 Mar 2011 15:42:32 +0200, "Christian Walde" <mithaldu@yahoo.de> said:
    Maybe sometime in the future i'll build a build_dir_reuse function
    that can do the same job without increasing ENV vars massively.
    Good luck! David and I have tried hard but failed. You find the traces
    of the failed experiment in the repository under CPAN/PERL5INC.pm. I do
    not even remember the details.

    --
    andreas
  • Christian Walde at Mar 30, 2011 at 5:10 pm

    On Wed, 30 Mar 2011 18:57:28 +0200, Andreas J. Koenig wrote:

    On Wed, 30 Mar 2011 15:42:32 +0200, "Christian Walde" <mithaldu@yahoo.de> said:
    Maybe sometime in the future i'll build a build_dir_reuse function
    that can do the same job without increasing ENV vars massively.
    Good luck! David and I have tried hard but failed. You find the traces
    of the failed experiment in the repository under CPAN/PERL5INC.pm. I do
    not even remember the details.
    Thanks. :)

    I'll certainly give it a try, since i have an idea that i believe can work. As for PERL5INC, could you be a bit more specific maybe? I checked out the github repo and couldn't find a trace of such a file, nor any branch hinting at it.

    --
    With regards,
    Christian Walde
  • Andreas J. Koenig at Mar 30, 2011 at 10:32 pm

    On Wed, 30 Mar 2011 19:10:28 +0200, "Christian Walde" <mithaldu@yahoo.de> said:
    I'll certainly give it a try, since i have an idea that i believe
    can work. As for PERL5INC, could you be a bit more specific maybe? I
    checked out the github repo and couldn't find a trace of such a
    file, nor any branch hinting at it.
    I found it again with

    git log -p

    and then enter: "/CPAN\/PERL5INC" (without the quotes)

    commit 327430cd7f57d421a9e4cba1d708fef4c7e14b12 was the one that removed
    the whole idea.

    --
    andreas
  • Christian Walde at Mar 31, 2011 at 7:02 am

    On Thu, 31 Mar 2011 00:32:12 +0200, Andreas J. Koenig wrote:

    On Wed, 30 Mar 2011 19:10:28 +0200, "Christian Walde" <mithaldu@yahoo.de> said:
    I'll certainly give it a try, since i have an idea that i believe
    can work. As for PERL5INC, could you be a bit more specific maybe? I
    checked out the github repo and couldn't find a trace of such a
    file, nor any branch hinting at it.
    I found it again with

    git log -p

    and then enter: "/CPAN\/PERL5INC" (without the quotes)

    commit 327430cd7f57d421a9e4cba1d708fef4c7e14b12 was the one that removed
    the whole idea.
    Thanks a lot. I really need to learn more about git. :)

    And yeah, that is an interesting approach, but i can see how it would be pretty painful to get working reliably.

    What i am thinking about is a bit more simplicistic. The sub set_perl5lib is responsible for going through the internal is_tested list and prepending its contents onto PERL5LIB. What i'd change it to is a function that instead creates a temp dir in something like .cpan/build_reuse/******, copies all the blibs and archs into that and then prepends that. It's a bit more work file-system-wise, but it should be pretty reliable.

    (Something else i'd like to solve there is a filtering of which of these dists are actually prereqs and which aren't.)

    If you have any thoughts on this approach, please let me know. :)

    --
    With regards,
    Christian Walde
  • Christian Walde at Apr 3, 2011 at 9:08 pm

    On Wed, 30 Mar 2011 18:57:28 +0200, Andreas J. Koenig wrote:

    On Wed, 30 Mar 2011 15:42:32 +0200, "Christian Walde" <mithaldu@yahoo.de> said:
    Maybe sometime in the future i'll build a build_dir_reuse function
    that can do the same job without increasing ENV vars massively.
    Good luck! David and I have tried hard but failed. You find the traces
    of the failed experiment in the repository under CPAN/PERL5INC.pm. I do
    not even remember the details.
    I just pushed a first sketch of the base functionality to this commit in my fork: https://github.com/wchristian/cpanpm/commit/858dd51110fdbf7bb8bbaa73dc24a073ee1ae346

    The reasoning behind this so far:

    - At this time in execution we do not know yet what the build dir of the dist were going to work on is.
    - It is reasonable to assume that at any given time there will only be one test running.
    - The temp dir creation code of Distribution.pm is a mess and not easily extracted, so before it could be used here, refactoring is necessary.

    As such, the changes are as follows:
    - If File::Copy::Recursive the old perl5lib-prepending mechanism is used.
    - Otherwise $CPAN::META->{cachemgr}->dir.'/build_merge' is first deleted entirely, then remade.
    - File::Copy::Recursive is used to copy the contents of all arch and blib dirs into build_merge.
    - That dir is prepended to perl5lib.

    The test suite of CPAN itself passes fine with this change and F::C::R installed and i'll do some real life testing tomorrow, using dists that would otherwise break on WinXP. (Hello Tapper::*!)

    Otherwise, the hard part about this is now the bike-shedding and i REALLY hope i'll get some feedback on this. Things i'm pondering:

    - Should i make the effort to create a temp dir with a randomized name instead, by factoring out the functionality in Distribution.pm?
    - Would it be better to copy parts of F::C::R into CPAN itself?
    - Is this fine as letting it pick up on F::C::R automatically, or should it maybe become an o conf option?
    - I really wonder what all little hooks and problems i missed.

    Only remotely related:
    - How open is CPAN.pm to pull requests that consist only of refactorings to reduce the amount of code duplication?

    --
    With regards,
    Christian Walde
  • David Golden at Apr 4, 2011 at 2:08 am

    On Sun, Apr 3, 2011 at 5:08 PM, Christian Walde wrote:
    Only remotely related:
    - How open is CPAN.pm to pull requests that consist only of refactorings to
    reduce the amount of code duplication?
    I have no time to think about the real issue, but I'm +1 for
    refactoring. I've been doing it where I can when I work on stuff. I'd
    be happy to see more of it.

    *However* -- test coverage is really low, so refactoring can seem safe
    but we're operating without a net. I'd love to see someone work up
    some good regression testing to support refactoring.

    -- David
  • Christian Walde at Apr 4, 2011 at 8:07 am

    On Mon, 04 Apr 2011 04:07:39 +0200, David Golden wrote:
    On Sun, Apr 3, 2011 at 5:08 PM, Christian Walde wrote:
    Only remotely related:
    - How open is CPAN.pm to pull requests that consist only of refactorings to
    reduce the amount of code duplication?
    I have no time to think about the real issue, but I'm +1 for
    refactoring. I've been doing it where I can when I work on stuff. I'd
    be happy to see more of it.
    Awesome, thanks for the answer.
    *However* -- test coverage is really low, so refactoring can seem safe
    but we're operating without a net. I'd love to see someone work up
    some good regression testing to support refactoring.
    Alright, i love writing tests. A few questions on that though:

    - What perl version is targeted by future CPANs?
    - What restrictions/procedures lie on pulling in modules beyond what CPAN/core ship? (Specifically, Capture::Tiny seems indispensible for building up a good test suite.)

    --
    With regards,
    Christian Walde
  • David Golden at Apr 4, 2011 at 10:40 am

    On Mon, Apr 4, 2011 at 4:07 AM, Christian Walde wrote:
    Alright, i love writing tests. A few questions on that though:

    - What perl version is targeted by future CPANs?
    I think Andreas wants to keep it working "as far back as possible". I
    forget if he actually gave me a target Perl, though. I try to avoid
    anything that requires 5.6 or higher. (Yes, painful, that.)
    - What restrictions/procedures lie on pulling in modules beyond what
    CPAN/core ship? (Specifically, Capture::Tiny seems indispensible for
    building up a good test suite.)
    I think you would need to make them conditional -- if installed, then
    you can run the tests, otherwise skip.

    As much as I'd love to see Capture::Tiny in core, I don't think
    there's a burning need for it yet. :-)

    -- David
  • Christian Walde at Mar 30, 2011 at 2:31 pm

    On Wed, 30 Mar 2011 16:21:36 +0200, Eric Brine wrote:

    Is taint on? Perl ignores PERL5LIB then.
    No, not that easy i'm afraid, the issue is different and actually a perl core bug occuring only on Windows 7. I've reported it here: http://rt.perl.org/rt3/Ticket/Display.html?id=87322

    --
    With regards,
    Christian Walde

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-testers-discuss @
categoriesperl
postedMar 30, '11 at 12:22a
activeApr 4, '11 at 10:40a
posts13
users5
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase