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

login
register
mail settings
Submitter Augie Fackler
Date June 8, 2017, 2:52 p.m.
Message ID <ef19f4139ca98d49f506.1496933530@augie-macbookpro2.roam.corp.google.com>
Download mbox | patch
Permalink /patch/21248/
State Accepted
Headers show

Comments

Augie Fackler - June 8, 2017, 2:52 p.m.
# HG changeset patch
# User Augie Fackler <augie@google.com>
# Date 1496762198 14400
#      Tue Jun 06 11:16:38 2017 -0400
# Node ID ef19f4139ca98d49f50677a7465cb5e750dbce60
# Parent  510ffdb1a28bf8acab7ebe9d2c79af4555ac398e
tests: add a test for installing hg with pip in a virtualenv

Since we're doing so much clever junk in our setup.py, let's have a
test that exercises it.

Thanks to Matt Harbison for testing this on Windows and verifying that
installenv/*/hg would work as a way to work around bin being called
Scripts on Windows.
Matt Harbison - June 9, 2017, 1:01 a.m.
On Thu, 08 Jun 2017 10:52:10 -0400, Augie Fackler <raf@durin42.com> wrote:

> # HG changeset patch
> # User Augie Fackler <augie@google.com>
> # Date 1496762198 14400
> #      Tue Jun 06 11:16:38 2017 -0400
> # Node ID ef19f4139ca98d49f50677a7465cb5e750dbce60
> # Parent  510ffdb1a28bf8acab7ebe9d2c79af4555ac398e
> tests: add a test for installing hg with pip in a virtualenv

LGTM, thanks!
Yuya Nishihara - June 9, 2017, 1:21 p.m.
On Thu, 08 Jun 2017 21:01:07 -0400, Matt Harbison wrote:
> On Thu, 08 Jun 2017 10:52:10 -0400, Augie Fackler <raf@durin42.com> wrote:
> 
> > # HG changeset patch
> > # User Augie Fackler <augie@google.com>
> > # Date 1496762198 14400
> > #      Tue Jun 06 11:16:38 2017 -0400
> > # Node ID ef19f4139ca98d49f50677a7465cb5e750dbce60
> > # Parent  510ffdb1a28bf8acab7ebe9d2c79af4555ac398e
> > tests: add a test for installing hg with pip in a virtualenv
> 
> LGTM, thanks!

Queued per review, thanks.
via Mercurial-devel - June 10, 2017, 5:49 a.m.
On Fri, Jun 9, 2017 at 6:21 AM, Yuya Nishihara <yuya@tcha.org> wrote:
> On Thu, 08 Jun 2017 21:01:07 -0400, Matt Harbison wrote:
>> On Thu, 08 Jun 2017 10:52:10 -0400, Augie Fackler <raf@durin42.com> wrote:
>>
>> > # HG changeset patch
>> > # User Augie Fackler <augie@google.com>
>> > # Date 1496762198 14400
>> > #      Tue Jun 06 11:16:38 2017 -0400
>> > # Node ID ef19f4139ca98d49f50677a7465cb5e750dbce60
>> > # Parent  510ffdb1a28bf8acab7ebe9d2c79af4555ac398e
>> > tests: add a test for installing hg with pip in a virtualenv
>>
>> LGTM, thanks!
>
> Queued per review, thanks.

And accepted per review. I have almost no idea what this series does
(I think it's something about packaging). Thanks for reviewing, Matt!

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Danek Duvall - June 19, 2017, 7:49 p.m.
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?

Danek
Augie Fackler - June 19, 2017, 10:11 p.m.
> On Jun 19, 2017, at 15:49, Danek Duvall <danek.duvall@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...)


> 
> Danek
Donald Stufft - June 19, 2017, 10:13 p.m.
> On Jun 19, 2017, at 6:11 PM, Augie Fackler <raf@durin42.com> wrote:
> 
> 
>> On Jun 19, 2017, at 15:49, Danek Duvall <danek.duvall@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
Augie Fackler - June 19, 2017, 10:15 p.m.
> On Jun 19, 2017, at 18:13, Donald Stufft <donald@stufft.io> wrote:
> 
>>> 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?

That sounds like exactly what I want - do you know how to do that? Is that the --never-download flag which says it does nothing on my Python 2.7.13? (but maybe Danek has an older virtualenv?)
Donald Stufft - June 19, 2017, 10:18 p.m.
> On Jun 19, 2017, at 6:15 PM, Augie Fackler <raf@durin42.com> wrote:
> 
> 
>> On Jun 19, 2017, at 18:13, Donald Stufft <donald@stufft.io> wrote:
>> 
>>>> 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?
> 
> That sounds like exactly what I want - do you know how to do that? Is that the --never-download flag which says it does nothing on my Python 2.7.13? (but maybe Danek has an older virtualenv?)


There is.. some history here. Basically if you have an old version of virtualenv —no-download / —never-download will turn off downloading from PyPI… if you have a recent but not super recent version of virtualenv, —no-download / —never-download does nothing (because we ripped out the network code for awhile), then if you have a recent version of virtualenv, —no-download / —never-download disables the new on-by-default code to pull down the latest pip/setuptools/etc.

So tl;dr; use —no-download.

—
Donald Stufft
Danek Duvall - June 19, 2017, 10:20 p.m.
Augie Fackler wrote:

> 
> > On Jun 19, 2017, at 18:13, Donald Stufft <donald@stufft.io> wrote:
> > 
> >>> 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?
> 
> That sounds like exactly what I want - do you know how to do that? Is
> that the --never-download flag which says it does nothing on my Python
> 2.7.13? (but maybe Danek has an older virtualenv?) 

We have virtualenv 15.0.1, on S12, and 12.0.7 on 11.3.  Python is 2.7.13
and 2.7.9, respectively.

Oddly, --never-download says it's deprecated on 12.0.7, but not on 15.0.1
(where it's also added the --no-download alias).

Danek
Danek Duvall - June 19, 2017, 10:22 p.m.
Donald Stufft wrote:

> 
> > On Jun 19, 2017, at 6:15 PM, Augie Fackler <raf@durin42.com> wrote:
> > 
> > 
> >> On Jun 19, 2017, at 18:13, Donald Stufft <donald@stufft.io> wrote:
> >> 
> >>>> 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?
> > 
> > That sounds like exactly what I want - do you know how to do that? Is that the --never-download flag which says it does nothing on my Python 2.7.13? (but maybe Danek has an older virtualenv?)
> 
> 
> There is.. some history here. Basically if you have an old version of virtualenv —no-download / —never-download will turn off downloading from PyPI… if you have a recent but not super recent version of virtualenv, —no-download / —never-download does nothing (because we ripped out the network code for awhile), then if you have a recent version of virtualenv, —no-download / —never-download disables the new on-by-default code to pull down the latest pip/setuptools/etc.
> 
> So tl;dr; use —no-download.

Why not --never-download, since all versions will understand it?

Danek
Danek Duvall - June 19, 2017, 10:38 p.m.
Danek Duvall wrote:

> Augie Fackler wrote:
> 
> > 
> > > On Jun 19, 2017, at 18:13, Donald Stufft <donald@stufft.io> wrote:
> > > 
> > >>> 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?
> > 
> > That sounds like exactly what I want - do you know how to do that? Is
> > that the --never-download flag which says it does nothing on my Python
> > 2.7.13? (but maybe Danek has an older virtualenv?) 
> 
> We have virtualenv 15.0.1, on S12, and 12.0.7 on 11.3.  Python is 2.7.13
> and 2.7.9, respectively.
> 
> Oddly, --never-download says it's deprecated on 12.0.7, but not on 15.0.1
> (where it's also added the --no-download alias).

And, FWIW, adding --never-download to the invocation allows the test to
succeed for me.

Thanks,
Danek
Donald Stufft - June 19, 2017, 10:58 p.m.
> On Jun 19, 2017, at 6:22 PM, Danek Duvall <danek.duvall@oracle.com> wrote:
> 
> Why not --never-download, since all versions will understand it?
> 


Because I didn’t remember which came first and —no-download was less letters to type ;)


—
Donald Stufft

Patch

diff --git a/tests/test-install.t b/tests/test-install.t
--- a/tests/test-install.t
+++ b/tests/test-install.t
@@ -173,3 +173,40 @@  path variables are expanded (~ is the sa
   Not tracked:
 
 #endif
+
+#if virtualenv
+
+Verify that Mercurial is installable with pip. Note that this MUST be
+the last test in this file, because we do some nasty things to the
+shell environment in order to make the virtualenv work reliably.
+
+  $ cd $TESTTMP
+Note: --no-site-packages is deprecated, but some places have an
+ancient virtualenv from their linux distro or similar and it's not yet
+the default for them.
+  $ unset PYTHONPATH
+  $ $PYTHON -m virtualenv --no-site-packages installenv >> pip.log
+Note: we use this weird path to run pip and hg to avoid platform differences,
+since it's bin on most platforms but Scripts on Windows.
+  $ ./installenv/*/pip install $TESTDIR/.. >> pip.log
+  $ ./installenv/*/hg debuginstall || cat pip.log
+  checking encoding (ascii)...
+  checking Python executable (*) (glob)
+  checking Python version (2.*) (glob)
+  checking Python lib (*)... (glob)
+  checking Python security support (*) (glob)
+    TLS 1.2 not supported by Python install; network connections lack modern security (?)
+    SNI not supported by Python install; may have connectivity issues with some servers (?)
+  checking Mercurial version (*) (glob)
+  checking Mercurial custom build (*) (glob)
+  checking module policy (*) (glob)
+  checking installed modules (*/mercurial)... (glob)
+  checking registered compression engines (*) (glob)
+  checking available compression engines (*) (glob)
+  checking available compression engines for wire protocol (*) (glob)
+  checking templates ($TESTTMP/installenv/*/site-packages/mercurial/templates)... (glob)
+  checking default template ($TESTTMP/installenv/*/site-packages/mercurial/templates/map-cmdline.default) (glob)
+  checking commit editor... (*) (glob)
+  checking username (test)
+  no problems detected
+#endif