No such option: --disable-pip-version-check

[mcyprian]

When I run:

>>> env = VirtualEnvironment('/tmp/venv')
>>> env.is_installed('jinja2')

The last command fails with an error:
subprocess.CalledProcessError: Command '<subprocess.Popen object at 0x7fb69ffbacd0>' returned non-zero exit status 2

error output: ('', '\nUsage: \n /tmp/venv/bin/python -m pip [options]\n\nno such option: --disable-pip-version-check\n') (it seems raw_pip argument of _execute_pip method is False)

Arguments of subprocess are: ARGS:['bin/python', '-m', 'pip', '--disable-pip-version-check', '-V']

pip version is 8.1.2

[sjkingo]

That's strange - --disable-pip-version-check was added somewhere around version 6 and should definitely work in 8.1.2.

Could you run the following from the manually activated environment (must be activated) and paste output:

python -V ; pip -V ; pip -h | grep disable-pip-version-check

Thanks

[sjkingo]

Regardless of your pip version, we really shouldn't error out like that if the pip version is too old to have that argument. I'll push a patch shortly.

[mcyprian]

Here is the output:

Python 2.7.5
pip 8.1.2 from /usr/lib/python2.7/site-packages (python 2.7)
--disable-pip-version-check

option is of course there,
Running

python -m pip --disable-pip-version-check -V

in terminal works fine, problem might be in arguments passing to subprocess.

[sjkingo]

Could you show the output of echo $VIRTUAL_ENV?

Looks like it's getting pip from the system site-wide instead of the virtualenv, which may be causing an issue.

[mcyprian]

Problem is that virtualenv is old, and pip inside virtualenv is very old as well v1.4.1. I think the only thing this project can improve is to show nicer error message in this case. It seems that even stderr of subprocess is hidden by default.

[sjkingo]

That would be it - the VirtualEnvironment class calls pip from inside the environment, which is usually $VIRTUAL_ENV/bin/pip - not necessarily the system pip. So in your case it's calling a version of pip that doesn't support that flag. But that's not your fault - we never intended to not support older versions of pip and the library shouldn't error out just because an argument isn't supported.

I will push a fix shortly and you can try that if you'd like.

[sjkingo]

One last thing, could you please try the following code in a Python shell and paste output:

>>> from virtualenvapi.manage import VirtualEnvironment
>>> v = VirtualEnvironment('/tmp/venv')
>>> v.pip_version

Thanks

[mcyprian]

Sure

>>> from virtualenvapi.manage import VirtualEnvironment
>>> v = VirtualEnvironment('/tmp/venv')
>>> v.pip_version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/virtualenvapi/manage.py", line 67, in pip_version
    string_version = self._execute_pip(['-V']).split()[1]
  File "/usr/lib/python2.7/site-packages/virtualenvapi/manage.py", line 129, in _execute_pip
    return self._execute(exec_args, log=log)
  File "/usr/lib/python2.7/site-packages/virtualenvapi/manage.py", line 153, in _execute
    raise e
subprocess.CalledProcessError: Command '<subprocess.Popen object at 0x7f33dcdd0fd0>' returned non-zero exit status 2

$ /tmp/venv/bin/python -m pip -V
pip 1.4.1 from /tmp/venv/lib/python2.7/site-packages (python 2.7)

[sjkingo]

Would you be able to try updating to commit e3c05af and seeing if that resolves the issue?

This should do the trick:

$ pip install -U -e git+https://github.com/sjkingo/virtualenv-api@e3c05af60081379d26765a5c54133476fb551175#egg=virtualenv-api

If that works I'll release a new version on PyPi.

Thanks

[mcyprian]

Yes, it works fine now, thank you very much.

[sjkingo]

2.1.16 has just been released on PyPi that includes this fix.

Thanks!