pip install virtualenvwrapper dependency resolution does not honor pip proxy settings

78 views
Skip to first unread message

James Smith

unread,
Apr 28, 2017, 9:56:57 AM4/28/17
to virtualenvwrapper
Problem:  For some reason trying to pip install virtualenvwrapper is causing my system to attempt directly reaching the Internet, bypassing my nexus caching server.

Basics of environment:
CentOS Linux release 7.3.1611 (Core)  behind firewall restricting all outbound traffic except to nexus proxy server.
Python 2.7.5
pip 9.0.1 from /usr/lib/python2.7/site-packages (python 2.7)

/etc/pip.conf:
  [global]
  index = https://mynexusserver.local/repository/python-group/pypi
  index-url = https://mynexusserver.local/repository/python-group/simple
  cert = /etc/pki/tls/mynexusserver.cert.pem



Expected Behavior: pip install virtualenvwrapper to proxy through my nexus server and install virtualenvwrapper without issue.

Actual Behavior:  pip install virtualenvwrapper starts by downloading the virtualenvwrapper package correctly (it seems), but then hangs during the dependency resolution.

Workaround:  If I temporarily allow my testbed outbound 443 access directly to the Internet, the dependencies are pulled from a standard PyPi server, and then all of the packages are downloaded via my nexus proxy as expected.  This would seem to indicate it is only the dependency resolution that actually requires access to the Internet.


Question:  Why does the virtualenvwrapper package require direct Internet access to resolve it's dependencies?  No other package I've attempted to install has this behavior.


Hoping someone has an obvious answer I've overlooked.

-James

Doug Hellmann

unread,
Apr 28, 2017, 10:37:44 AM4/28/17
to virtuale...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "virtualenvwrapper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualenvwrap...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The only thing I can think of that might be different about virtualenvwrapper’s packaging and other sdists is the use of pbr as a setup_requires dependency. If you “pip install pbr” before you install virtualenvwrapper, does that resolve the issue?

If so, I think that qualifies as a bug in pip and/or setuptools.

Doug

James Smith

unread,
Apr 28, 2017, 11:50:16 AM4/28/17
to virtualenvwrapper
That was it.  With that I can keep my firewall locked down.

Wonder why this doesn't work automatically, but works if I install it first?

Thanks, Doug!

James Smith

unread,
Apr 28, 2017, 1:23:36 PM4/28/17
to virtualenvwrapper
There is another issue to troubleshoot, but that doesn't have to do with this.  Interestingly, with this issue solved I've discovered that now I get a call home request after any pip check on virtualenvwrapper.  System will continue attempting to hit python.org for ~120 seconds, then timeout and return that everything is fine. 

Doug Hellmann

unread,
Apr 28, 2017, 2:23:48 PM4/28/17
to virtuale...@googlegroups.com
The path through pip & setuptools is different for dependencies that are listed as being needed to process the setup.py for something being installed. That path is missing quite a few of the features of the main pip installation step. Please file a bug with the PyPA folks about this case (it’s not specific to pbr, but there are not a lot of other packages that use the setup_requires hook).

Doug

Doug Hellmann

unread,
Apr 28, 2017, 2:25:16 PM4/28/17
to virtuale...@googlegroups.com
I have no idea what pip is doing there. Is pip trying to determine the latest version of the package?

On Apr 28, 2017, at 1:23 PM, James Smith <jamesd...@gmail.com> wrote:

There is another issue to troubleshoot, but that doesn't have to do with this.  Interestingly, with this issue solved I've discovered that now I get a call home request after any pip check on virtualenvwrapper.  System will continue attempting to hit python.org for ~120 seconds, then timeout and return that everything is fine. 

Reply all
Reply to author
Forward
0 new messages