Issue #106 resolved

Create virtualenvs from alternate virtualenv versions

duplicate account
created an issue

I want to create virtualenvs from non-system virtualenv source code, for example because the system-installed package is out-of-date. Please add an option to use an alternate version of virtualenv when creating an environment.

At the moment I use this method which is based on this method

Hopefully that gives you an idea of what I'm trying to achieve (and how it may relate to ). My impression is that this is a core change rather than something that can be done with an extension, if I'm wrong please point me in the right direction!

Comments (5)

  1. Doug Hellmann repo owner

    You can set VIRTUALENVWRAPPER_VIRTUALENV to point to the virtualenv binary that you want to use. Are you asking for a command line option of some sort, too? Do you want to choose the virtualenv binary each time you run mkvirtualenv, or once when you configure the wrappers?

  2. duplicate account reporter

    For my purposes, once is enough, I'll just update VIRTUALENVWRAPPER_VIRTUALENV every time I get a new binary.

    I assume the following should work:

    1. download virtualenv .tar.gz (latest or specific version) from PyPI
    2. untar to storage folder
    3. point VIRTUALENVWRAPPER_VIRTUALENV environment variable to in that folder
    4. now using preferred virtualenv version
    5. to achieve issue 105, create virtualenv with -p (preferred python version)

    I'll write my own script for 1-4, but if it were in scope for virtualenvwrapper, I think it'd make a great addition.

  3. duplicate account reporter

    Speaking personally, I'm on Ubuntu and would prefer not to mess or hassle with my system packages. So if there's a new virtualenv release that I want to use (*) I need to download it and use it separately. Of course, on the off-chance there's a bug or some kind of incompatibility, I'd like to be able to easily switch back to the previous version.

    Also, others in my team use different distros, and Windows, and install things at different times, so this is part of an attempt to a) make it easy for everyone to be on the same version and b) try out alternatives.

    So basically, the benefit is that it makes my testing/switching cycle a lot easier - I'm not sure how universal a need this is :)

    (*) it fixes a bug, introduces a new feature, or just updates pip/Distribute

  4. Doug Hellmann repo owner

    OK, so it's not a matter of having 3 versions installed and choosing between them each time you create an environment as much as having 1 version installed somewhere "non-standard" that you want to use. That's what the variable is for, so I think we're covered. :-)

  5. Log in to comment