无法在代理下安装 WWW::Mechanize

Question

操作系统：Linux。 Perl 版本：5.16.0（使用 Perlbrew）。

我尝试安装 Catalyst，但测试失败，完全符合以下说明：

http://stevemoss.posterous.com/installing-wwwmechanize-and-testwwwmechanize

我在工作场所的代理下运行，我在 ~/.cpan/CPAN/Config.pm 中设置了 http_proxy 并将 no_proxy 设置为以下各项，但均未成功： 1.本地主机。 2. 127.0.0.1（本地主机ip）。 3.我测试过的一个已知的http服务器没有代理。 4. 空白。

这里是失败的测试日志，最后一个甚至没有结束，卡在 44/47：

rlbrew/perls/perl-5.16.0/bin/perl
# Test::Memory::Cycle 1.04 is installed.
t/00-load.t .............. ok   
t/add_header.t ........... ok   
t/aliases.t .............. ok   
t/area_link.t ............ ok   
t/autocheck.t ............ ok   
t/clone.t ................ ok   
t/content.t .............. ok   
t/cookies.t .............. # Test server http://127.0.0.1:22443 as PID 4655
t/cookies.t .............. ok     
t/credentials-api.t ...... Use of uninitialized value in lc at /perl5/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0/LWP/UserAgent.pm line 605.
t/credentials-api.t ...... ok   
t/credentials.t .......... ok     
t/die.t .................. ok   
t/field.t ................ ok   
t/find_frame.t ........... ok   
t/find_image.t ........... ok     
t/find_inputs.t .......... ok     
t/find_link-warnings.t ... ok     
t/find_link.t ............ ok     
t/find_link_id.t ......... ok    
t/form-parsing.t ......... ok   
t/form_with_fields.t ..... 1/? There are 2 forms with the named fields.  The first one was used. at t/form_with_fields.t line 27.
t/form_with_fields.t ..... ok   
t/frames.t ............... ok   
t/image-new.t ............ ok     
t/image-parse.t .......... ok     
t/link-base.t ............ ok   
t/link-relative.t ........ ok   
t/link.t ................. ok     
t/local/back.t ........... 44/47 

Answer 1

这似乎不是重要的问题。您可以强制安装模块：

cpan -f -i WWW::Mechanize

Answer 2

这里的问题显然不是您的 CPAN 客户端无法正确使用代理（毕竟它设法下载了软件包），而是您正在安装的模块不知道代理或尚未准备好处理代理。

如果您尝试安装的模块无法处理，代理，您就不走运了。

如果可以，通过设置相关的环境变量告诉它使用你的代理：

export http_proxy="http://your.proxy.goes.here"

Answer 3

对于 local/back.t（和其他几个测试），http_proxy 被暂时禁用。您可能会遇到一种竞争条件，即在重新激活 http_proxy 之前临时服务器（在测试中创建）没有被销毁。

幸运的是，no_proxy 在测试期间没有被禁用，它应该能够解决问题。只需确保将其设置为“localhost”而不是“本地主机”，就像您为选项 #1 编写的那样。

如果这不起作用，请检查 NO_PROXY 的配置是否正确，方法是暂时将其设置为外部站点（但无法访问它）。当然，删除所有提及 http_proxy 是另一种选择，但这有时会很尴尬，并且会导致其他测试失败。