[PATCH 3 of 3 v2 pip-fix] tests: add a test for installing hg with pip in a virtualenv

[Donald Stufft]

> On Jun 19, 2017, at 6:11 PM, Augie Fackler <raf at durin42.com> wrote:
> 
> 
>> On Jun 19, 2017, at 15:49, Danek Duvall <danek.duvall at oracle.com> wrote:
>> 
>> I've been running into problems with this.  It's not a Solaris issue, but
>> because I'm running inside a non-transparent firewall.
>> 
>> http_proxy is being stripped from the environment of each test, but in
>> order to do a pip install, I need that environment variable in order to
>> connect outside.
>> 
>> I also need to have virtualenv on the system, so I can't disable the test
>> by making sure the #if evaluates to false.
>> 
>> I'm not sure why this isn't failing on the buildbot instances, which should
>> have the same issue.
>> 
>> Any thoughts on what to do here?  The ping command has a different
>> interface on Solaris than on Linux, so trying to simply ping
>> pypi.python.org (assuming we can rely on pip always trying that host) is
>> going to run into platform-specific issues.  We could save http_proxy
>> aside, and enable it here specifically (somehow).  Or we could allow for
>> specific "have"s to be blacklisted, and introduce some sort of
>> external-network #if token, maybe?
> 
> I was going to suggest an hghave check that lets us be sure we can see authentic pypi - dstufft, do you have some endpoint that'd be suitable for such a sniff-test?
> 
> (The test in question is an end-to-end setup.py install test that makes a virtualenv, which I think is failing because it wants to slurp down pip and setuptools...)
> 



You could just tell virtualenv not to pull down the latest pip/setuptools/etc? That seems like the best solution here since presumably you don’t want your tests hitting the network unless required anyways?

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170619/632314e2/attachment.html>