Corion / WWW-Mechanize-Chrome

automate the Chrome browser
https://metacpan.org/release/WWW-Mechanize-Chrome
Artistic License 2.0
30 stars 12 forks source link

Sdondley #7

Closed sdondley closed 6 years ago

sdondley commented 6 years ago

Hi, I'm not sure if I'm doing the correctly or not via github but I'd like to make the following addition to the documentation. Please advise.

Corion commented 6 years ago

Thank you very much for the instructions on Mac OS!

Would it make sense to set /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome as the default Chrome version to use if none was specified? It would be great if you could test the following change on your system:

sub find_executable( $class, $program=undef, @search ) {
    $program ||=
          $^O =~ /mswin/i ? 'chrome.exe'
        : $^O =~ /darwin/i ? 'Google Chrome'
        : 'google-chrome';

    push @search, File::Spec->path();

    if( $^O =~ /MSWin/i ) {
        push @search,
            map { "$_\\Google\\Chrome\\Application\\" }
            grep {defined}
            ($ENV{'ProgramFiles'},
             $ENV{'ProgramFiles(x86)'},
             $ENV{"ProgramFilesW6432"},
            );
    } elsif( $^O =~ /darwin/i ) {
        push @search, "/Applications/Google\ Chrome.app/Contents/MacOS/";
    }
...

If that works, could you add it as another commit (or separate pull request) please?

Corion commented 6 years ago

The additional default for MacOS can simply come in a secondary change :)

sdondley commented 6 years ago

Yes, I'd be happy to help in any way I can be useful.

I'd like to try to add some more patches in the future. Though the module works perfectly fine on a Mac, I suspect the module is behaving a little wonky with regard to how the Chrome process is started and terminated. I'll open a separate issue on this once I do some more testing if I think it warrants a new issue.

I do need a bit of advice, though, on how to contribute to this project in an efficient manner. I'm a bit new at this. Please read on for more details.

I have installed your module from cpan (version .16) into a directory and ran Makefile.PL PREFIX=/my/install/directory. I can make changes to the code installation and experiment with it there. But I'm not quite sure how to integrate this installed, operational module with github.

For now, I have cloned a clean version WWW::Mechanize::Chrome into a separate directory, /my/git/directory, with git which I can use to create the pull requests to your repo.

Ideally, however, I'd like to have my git repo code and the installed module be the same code, if that's possible. Can you please offer some guidance on this? I'd be greatly appreciative.

Corion commented 6 years ago

Personally, I keep a "stable" version installed but for developing and testing my scripts with a future version, I run the scripts as follows:

perl -I/my/git/directory/lib ./myscript.pl

This will make Perl load WWW::Mechanize::Chrome from /my/git/directory/lib and then run my script with it.

If you always want to use the lastest git checkout as your current version, the easy approach is to use PERL5LIB:

export PERL5LIB=/my/git/directory/lib

This will make Perl look in /my/git/directory/lib for modules before it looks in other directories and thus your scripts will always use what's checked out from git.

Making changes to the installed module is a way to hide nasty bugs until you realize you were running a hacked version of a Perl module, so I try to avoid that.

sdondley commented 6 years ago

OK, great. I'll try that out later this week when I get some time. Thanks.

I just noticed that in my haste I forgot to change the backticks from the README file to proper POD syntax C== in my patch to the POD. I'll fix that up as well.

sdondley commented 6 years ago

OK, I just took a closer look at the instructions. So there is no need to run make Makefile.PL; make; make test; make; install on the module in /my/git/directory? That's where my confusion is.

Corion commented 6 years ago

Yes - the module doesn't need a real build step, so you can use it straight from lib/

Am 5. Juli 2018 04:07:50 MESZ schrieb Steve Dondley notifications@github.com:

OK, I just took a closer look at the instructions. So there is no need to run make Makefile.PL; make; make test; make; install on the module in /my/git/directory? That's where my confusion is.

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/Corion/WWW-Mechanize-Chrome/pull/7#issuecomment-402586592

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

sdondley commented 6 years ago

Thanks.

I have another question regarding this. If I try to run the module tests with make test located in /my/git/directory/lib I get the following error: make: *** No rule to make target 'test'. Stop.

If I try perl runtests.pl I get Can't locate object method "find_executable" via package "WWW::Mechanize::Chrome" at t/helper.pm line 43.

How do I run module tests on the code in the repository without installing the module?

sdondley commented 6 years ago

OK, I think I got it now. I looked in the .gitignore file and it seems that the files modified by the make commands are ignored. So I believe I can run make Makefile.PL and make on the git repo code and not have to worry about those changes getting added back to the repo.

So I ran make test with the code you suggested above and all tests passed. However, there were some warnings thrown. I will investigate.

Corion commented 6 years ago

Yes, that's the good approach to running the test suite and developping the module.