Issue #190 closed

-p works differently than --python

Vladislav Polukhin
created an issue

I use virtualenvwrapper 1.9.1. For example:

$ mkvirtualenv -p python2.7 test
The executable /home/user/python2.7 (from --python=/home/user/python2.7) does not exist

$ mkvirtualenv --python=python2.7 test 

$ mkvirtualenv -p $(which python2.7) test

Comments (9)

  1. Doug Hellmann repo owner

    Ensure that -p and --python options are consistent

    The option parsing in mkvirtualenv was not handling the long-form of --python with the value attached to the same argument using = (it only worked if the option and value were separate command line arguments).

    Addresses issue #190.

    Signed-off-by: Doug Hellmann

    → <<cset c91167dceebc>>

  2. jealous

    I've got 4.1.1 installed currently and it seems like a user can't use: mkvirtualenv -p python2.7 (or any other version) anymore without specifying the full path. 'python2.7' is accessible in my PATH, shouldn't it find it ? It pretty much gives me the same error as this 'issus 190' mentions. Not specifying the full path used to work. Is this an intentional new behavior, of having to specify the full path always ?

  3. Naoki INADA

    virtualenv allows -p python2.7.

    $ virtualenv -p python2.7 venv
    Running virtualenv with interpreter /usr/local/bin/python2.7
    New python executable in venv/bin/python2.7
    Also creating executable in venv/bin/python
    Installing setuptools, pip...done.

    Why does virtualenvwrapper prohibit it?

  4. Log in to comment