Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry

by pryrt (Abbot)
on Jan 01, 2019 at 16:17 UTC ( [id://1227880]=perlquestion: print w/replies, xml ) Need Help??

pryrt has asked for the wisdom of the Perl Monks concerning the following question:

SUMMARY:

I had difficulty trying to install WWW::Mechanize::Chrome on Windows Strawberry Perl. In the end, running the code from the synopsis seems to work, so I think it's been sufficiently installed. However, with the difficulties I encountered, I had some questions or discussion points to bring up:

  1. Do others have this much difficulty installing it on Windows?
  2. Is there a sequence that works to reliably install it on Windows (preferrably with cpanm) without resorting to multiple attempts, and --force? Does my detailed description below provide enough to give hints, if I'm just doing something wrong
  3. Does corion know that the cpantesters results "lie" about a successful windows install, due to not finding chrome.exe? Is there a way to make chrome.exe a prereq, so that cpantesters reports will be more useful
  4. is the failure i found in t/51-mech-links.t real, or an artifact of my problematic install? If it's real, is it a bug in the test suite, or a bug in the module itself?
  5. If my failures end up being invalid, is there a way to delete/override the failing reports to cpantesters? (added)

TL;DR:

My first attempt to install WWW::Mechanize::Chrome (using cpanm) failed bunches of pre-reqs. Multiple attempts on the prereqs got most working. In the end, the only two pre-req failures were AnyEvent and Log::Log4perl. The latter was a known issue (https://rt.cpan.org/Public/Bug/Display.html?id=120926), so I forced that install, because it's not a module-functionality issue

AnyEvent only fails t/81_hosts.t -- it seems to not be doing what was expected with the PERL_ANYEVENT_HOSTS temporary hosts file; I verified the temp file was created correctly, and populated as t/81_hosts.t implies it should... so I'm not sure whether there's a bug there, or what. I did a --force (for now), because I wasn't sure whether WWW::Mechanize::Chrome would depend on that feature or not. My cpantesters report is at http://www.cpantesters.org/cpan/report/500da4bb-75df-1014-a202-c39384fafcb3

After that, cpanm WWW::Mechanize::Chrome still failed, and I propagated that report to cpantesters: http://www.cpantesters.org/cpan/report/72e85fc1-75e8-1014-b1ad-07b284fafcb3. As the report shows, I'm on Windows with strawberry perl 5.28.1 (x64), with chrome.exe v71.0.3578.98. It's failing t/51-mech-links.t -- finding 3 links instead of expected 2

I was surprised I had so much difficulty, because the http://fast-matrix.cpantesters.org/?dist=WWW-Mechanize-Chrome%200.27 showed all passes under Windows (until my report, which was the first 5.28.1 on windows)... but when I dug into them, it's because none of them had chrome.exe

After I did a --force install, I was able to run the synopsis:

#!/usr/bin/env perl use 5.012; use warnings; use Log::Log4perl qw(:easy); use WWW::Mechanize::Chrome; Log::Log4perl->easy_init($ERROR); # Set priority of root logger t +o ERROR my $mech = WWW::Mechanize::Chrome->new(); $mech->get('https://google.com'); $mech->eval_in_page('alert("Hello Chrome")'); my $png= $mech->content_as_png();
... but I had to kill all pre-existing background chrome.exe tasks before it would respond (that may be normal, I've never used the module before).

so for the t/51-mech-links.t, I don't know whether that's a bug in the test suite, or in the actual module itself (or whether my earlier difficulties during the install process made something unstable for that test)

edit 1: fix typo in title

edit 2: add the fifth question in the SUMMARY

Replies are listed 'Best First'.
Re: Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry
by Corion (Patriarch) on Jan 01, 2019 at 17:57 UTC

     t/51-mech-links.t rightfully fails because on your system, you have a weirdo search engine or malware installed which injects a search engine link into the page:

    http://search.frontier.com/search/?q=http://somewhere.example/myiframe +&t=0

    This is not the fault of WWW::Mechanize::Chrome, but it's still a problematic Chrome installation. See WWW::Mechanize::Chrome::Troubleshooting for further information.

    As to your other questions:

    Do others have this much difficulty installing it on Windows?

    Personally, I develop under Windows and don't experience such problems, but I have AnyEvent installed and Log::Lo4perl as well..

    Is there a sequence that works to reliably install it on Windows (preferrably with cpanm) without resorting to multiple attempts, and --force? Does my detailed description below provide enough to give hints, if I'm just doing something wrong

    For me, the tests pass on my machine without problems. The tests fail on Travis CI from time to time due to timeouts and/or weirdo interactions between the VM and Chrome and (nonexistent) desktop environment, but I don't consider that problematic.

    Does corion know that the cpantesters results "lie" about a successful windows install, due to not finding chrome.exe? Is there a way to make chrome.exe a prereq, so that cpantesters reports will be more useful

    As I wrote the test suite so it skips the tests when the Chrome executable is unavailable, I guess I'm aware of that the tests get skipped when Chrome is not available. I wouldn't consider that a lie, especially when the tests themselves in the skip message say that they skipped the tests due to Chrome being unavailable. No, you cannot make non-Perl components a prerequisite. If you want more useful reports, see the Travis CI and AppVeyor reports where WWW::Mechanize::Chrome is tested on as well.

    Is the failure i found in t/51-mech-links.t real, or an artifact of my problematic install? If it's real, is it a bug in the test suite, or a bug in the module itself?

    As discussed above, it is a problem with your system and setup of Chrome. This is already discussed in the WWW::Mechanize::Chrome documentation, and while I think about making the test suite more resilient against such setups, you should still clean up your system and remove whatever plugin/malware injects new search links into your web pages.

    If my failures end up being invalid, is there a way to delete/override the failing reports to cpantesters? (added)

    Why would you want to delete that test run from CPAN testers?

      Thanks for the response.

      http://search.frontier.com/search/?q=http://somewhere.example/myiframe&t=0

      Ahh. It's not actually on my system: the same thing happens both on my phone thru WiFi at home, or on my PC. Based on the URL of frontier.com, my ISP is apparently "helping me" by injecting their search when I try to go to a domain that doesn't exist -- probably because I'm using their DNS. (The same thing happens whether through a browser on my PC, or whether on my phone thru wifi; if I switch my phone to just use its data plan, it properly tells me the domain somwehere.example doesn't exist.) Do you think that changing my DNS to a public server rather than my ISP's DNS server would get around this? I'll probably try that at some point

      Sorry for not seeing the ::Troublshooting docs: I didn't see it linked from the main POD or the ::Installing POD, so didn't notice it was in there. I now see it on the main https://metacpan.org/release/CORION/WWW-Mechanize-Chrome-0.27 page, though I'm not sure I would have noticed if I didn't know there was a page named ::Troubleshooting. I guess I need to read documents more thoroughly.

      I have AnyEvent installed and Log::Lo4perl as well

      That probably would have helped me. I wonder why AnyEvent doesn't seem to be problematic for you, when it is for me.

      "lie"

      That was too strong of a word on my part -- I put it in quotes to try to imply that "lie" wasn't exactly what I meant. I just don't like it when I see a "clean" cpantesters report, and it turns out it's because all the functionality testing is skipped because of missing external components. But since external components cannot be made pre-reqs, I guess there's not much that can be done on smoke testers machines. I wish more users would report their install successes and failures to cpantesters, so we can see more "practical" installs. Thanks for pointing out the travis-ci/appveyor results: I should have thought of looking for those.

      Are there any "true" failure modes -- ie, failures with your module, rather than weird system/ISP setups -- that would give a result of "3" instead of "2"? Or would it be possible to pass "2" or "3" as valid? if it really is my ISP's DNS doing it to me, then ISP=Frontier might mess up other Perl users, and there might be other ISPs who do it similarly to other people. (I mean, I know I'm not the only Frontier user in the world, though I may be the only Frontier user who also uses Perl (highly unlikely).)

      Why would you want to delete that test run from CPAN testers?

      since it's an invalid failure ("oops, my bad, nothing actually wrong with your module"), I guess I'd like to be able to erase that "strike" against your otherwise clean cpantesters matrix.

        http://search.frontier.com/search/?q=http://somewhere.example/myif +rame&t=0
        Ahh. It's not actually on my system: the same thing happens both on my phone thru WiFi at home, or on my PC. Based on the URL of frontier.com, my ISP is apparently "helping me" by injecting their search when I try to go to a domain that doesn't exist -- probably because I'm using their DNS.

        Aah, I see now. Maybe I can change that to a different, non-existing domain that does not get served by them. Maybe using localhost with a port number that is hopefully unused will work better, or have a different failure mode at least ...

Re: Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry
by Discipulus (Canon) on Jan 01, 2019 at 18:08 UTC
    Hello pryrt,

    About cpanm client read my Re: Should cpanminus be part of the standard Perl release? -- MSWin32 Infact I tryed it a bit and then I abandoned it.

    Using straberry perl 5.24 portable, after a first failed installation of WWW::Mechanize::Chrome I used force install Log::Log4perl I had no problem installing WWW::Mechanize::Chrome using classic cpan client.

    cpan> install WWW::Mechanize::Chrome ... CORION/WWW-Mechanize-Chrome-0.27.tar.gz C:\ulisse\perl5.24-64b\c\bin\dmake.exe install UNINST=1 -- OK

    Ahh.. ..oops I have not chrome instelled: sorry didnt read carefully: ok I install chrome, in the cpan client I look WWW::Mechanize::Chrome and there I prove -l -v (I think is correct) and I got:

    cpan> look WWW::Mechanize::Chrome cmd> prove -l -v ... t\51-mech-links.t ................ 1..7 # Testing with C:/Program Files (x86)/Google/Chrome/Application/chrome +.exe # Using Chrome version 'HeadlessChrome/71.0.3578.98' ok 1 - An object of class 'WWW::Mechanize::Chrome' isa 'WWW::Mechanize +::Chrome' ok 2 - All 5 links were found ok 3 - The two links were found ok 4 - BASE tags get respected ok 5 - BASE tags get respected for iframes ok 6 - FRAME tag ok 7 - IFRAME tag Couldn't kill pid '6776' at C:/ulisse/perl5.24-64b/perl/site/lib/Test/ +HTTP/LocalServer.pm line 237. ok ... All tests successful. Files=42, Tests=358, 263 wallclock secs ( 0.22 usr + 0.08 sys = 0.30 + CPU) Result: PASS

    the following weird behaviour is probably erroneous..

    update 3

    It must be something within look and the spawned cmd.exe inside the cpan client.. and can be related with my own distribution (I have a heavely modified cmd.exe). Infact if I run portableshell.bat inside the perl5.28 portable strawberry directory:

    C:\ulisse\perl5.28-64bit\cpan\build\WWW-Mechanize-Chrome-0.27-0> gmake + test ... All tests successful. Files=42, Tests=358, 257 wallclock secs ( 0.12 usr + 0.05 sys = 0.17 + CPU) Result: PASS

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      t/00-load.t expects "taint mode" to be on, so you need to run it manually as

      prove -T -l -v ./t/00-load.t

      I think when run as part of the CPAN test cycle, the taint switch gets automatically set.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1227880]
Front-paged by Discipulus
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-04-25 19:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found