Feature Request: Vox: Choose Python version with -p, similar to virtualenv and other tools

[moigagoo]

Currently, Vox invokes venv.create from Python 3 to create environments. This means that you can't create Python 2 environments.

Workaround: Create the environment in $VIRTUALENV_HOME (~/.virtualenvs by default) manually with virtualenv -p python2 ~./virtualenvs.

[moigagoo]

The problem with implementing this feature it we have to add virtualenv as a dependency.

[scopatz]

@moigagoo, as long as it is an optional dependency I don't see the problem.

[eykd]

+1 to this. I still need to be able to work with py2.7 virtualenvs, and I seem to be shut out from even using existing virtualenvs because bin/activate no longer works. 😢

[scopatz]

Pull requests most welcome! Preferably by someone who uses virtual envs :)

[eykd]

Who doesn't use virtualenvs? 😉 I don't understand xonsh's or virtualenv's inner workings well enough to dash anything off. Also, if pyenv is involved, it gets weird (the OP workaround doesn't work for me). I did, however, figure out a workaround, which may or not be helpful to anyone else.

Put this in your .xonshrc:

from os import path

def _venv(args, stdin=None):
    """venv <python-version> <env-name>

    Activate with `vox activate <env-name>`
    """
    version, name = args
    root = $PYENV_ROOT
    pyversion = '%(root)s/versions/%(version)s/bin/python' % locals()
    venv_path = path.join(path.expanduser('~/.virtualenvs'), name)
    print("Creating a virtualenv with Python %(version)s in %(venv_path)s" % locals())
    virtualenv -p @(pyversion) @(venv_path)


aliases['venv'] = _venv

UPDATED: Fixed the snippet to use os.path instead of path.py.

[scopatz]

Cool. Maybe you could add this the docs as a potential work around: http://xon.sh/python_virtual_environments.html

[Granitosaurus]

@eykd why break the virtualenv syntax though?

So this code is more straigh-forward and elegant:

#!/usr/bin/env xonsh
import os

def _venv(args, stdin=None):
    """
    venv <env-name> <python>
    Activate with `vox activate <env-name>`
    """
    name, version = args
    venv_path = os.path.join(os.path.expanduser('~/.virtualenvs'), name)
    print('Creating a virtualenv "{}" with "{}"'.format(name, version))
    virtualenv @(venv_path) -p @(version)

aliases['venv'] = _venv

venv <name> <python path or executable>.
vs
venv <python path> <name>

[scopatz]

Again, PRs welcome!

[AstraLuma]

This is a duplicate of #1588

[AstraLuma]

Need: Vox in xonsh from conda breaks. Should probably be detecting the correct python to use anyway.

[gforsyth]

Breaks how, @astronouth7303 ? Is it a problem with ensure_pip?

[AstraLuma]

Error: Command '['/home/jbliss/.virtualenvs/django_bm_engines/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

This might be a Debian thing, though. Happens even when I call python -m venv manually.

(This is why we can't have nice things.)

[deeuu]

Hey,

Is there still interest in this feature?

It seems a little strange having vox depend on virtualenv, simply to use vox as an activator, especially given the documentation intro.

It would be cool if vox could be directed to (or even better detect) the interpreter and use that.

Thoughts?

(Thanks for xonsh awesomeness).

[scopatz]

Hi @deeuu - I think that there is still interest in this.

Thanks for xonsh awesomeness

Thanks for using xonsh!

[worldmind]

Start experiment with pyenv and xonsh an found this question.
Installation of pyenv described here or, simple version that I trying, here, full dependencies here.
pyenv init source here

[worldmind]

My experiment:
sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev

git clone https://github.com/pyenv/pyenv.git ~/.pyenv

add to .xonshrc

$PYENV_ROOT = '%s/.pyenv' % $HOME
$PATH.insert(0, '%s/bin' % $PYENV_ROOT) 
# from SO question, not sure that is correct
pyenv init - > /tmp/pyenv
source-bash /tmp/pyenv > /dev/null

restart xonsh and install needed version of python
pyenv install 3.6.5

worldmind@host ~ master $ pyenv global 3.6.5
worldmind@host ~ master $ python --version
Python 3.6.5

I has avox with $PROJECT_DIRS = ["~/code"] for autoactivate vox env

worldmind@host ~ master $ mkdir code/test_env
worldmind@host ~ master $ cd code/test_env/
(test_env) worldmind@host ~/code/test_env master $ python --version
Python 3.5.3

looks like vox did not use pyenv python

[ghost]

knowsuchagency's PR (cf, #2968) would make vox pyenv-friendly, but relegate pyenv to a python version installer when used in conjunction with vox. This is the best solution, IMO, as vox would then take the absolute path to the desired interpreter, and that could be one that pyenv installed. I.e., vox new -p $(pyenv root)/versions/3.7/bin/python3.7.

Note the further benefit that vox could use the same interpreter and site packages as a venv, virtualenv or pyenv-virtualenv, allowing the user to activate the same virtual environment in any shell.

[worldmind]

@joseph8th thanks for information about PR.
@knowsuchagency many thanks for feature, I test it:

1. Install pyenv
   1. Install deps for pyenv.
   2. git clone https://github.com/pyenv/pyenv.git ~/.pyenv
   3. Add to .xonshrc and reload xonsh:

$PYENV_ROOT = '%s/.pyenv' % $HOME
$PATH.insert(0, '%s/bin' % $PYENV_ROOT)

2. Install needed python (pyenv install --list for available):
   pyenv install 3.7.2
3. Create env with this python:

mkdir projects/projectwith3.7
vox new -p $PYENV_ROOT/versions/3.7.2/bin/python projectwith3.7

4. Test it (I have avox installed):

cd projects/projectwith3.7/
(projectwith3.7) worldmind@x ~/projects/projectwith3.7 $ python --version
Python 3.7.2

Looks good!

[scopatz]

virtualenv supports xonsh now, and this has been implemented.