Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
moigagoo opened this issue Feb 19, 2016 · 18 comments

Comments

Projects
None yet
9 participants
@moigagoo
Copy link
Contributor

commented Feb 19, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 4, 2016

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

@scopatz

This comment has been minimized.

Copy link
Member

commented Mar 6, 2016

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

@scopatz scopatz added this to the v0.3 milestone Mar 6, 2016

@gforsyth gforsyth modified the milestones: v0.4.0, v0.3 May 26, 2016

@eykd

This comment has been minimized.

Copy link

commented Jun 15, 2016

+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

This comment has been minimized.

Copy link
Member

commented Jun 15, 2016

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

@eykd

This comment has been minimized.

Copy link

commented Jun 15, 2016

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

This comment has been minimized.

Copy link
Member

commented Jun 15, 2016

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

@Granitosaurus

This comment has been minimized.

Copy link
Contributor

commented Jun 30, 2016

@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

This comment has been minimized.

Copy link
Member

commented Jun 30, 2016

Again, PRs welcome!

@gforsyth gforsyth modified the milestones: v0.4.0, v0.5 Sep 9, 2016

@astronouth7303

This comment has been minimized.

Copy link
Member

commented Jan 15, 2017

This is a duplicate of #1588

@astronouth7303

This comment has been minimized.

Copy link
Member

commented May 10, 2017

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

@gforsyth

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2017

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

@astronouth7303

This comment has been minimized.

Copy link
Member

commented May 10, 2017

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

This comment has been minimized.

Copy link

commented Jun 4, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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

Thanks for xonsh awesomeness

Thanks for using xonsh!

@worldmind

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

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

@joseph8th

This comment has been minimized.

Copy link

commented Dec 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

@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)
  1. Install needed python (pyenv install --list for available):
    pyenv install 3.7.2
  2. Create env with this python:
mkdir projects/projectwith3.7
vox new -p $PYENV_ROOT/versions/3.7.2/bin/python projectwith3.7
  1. 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.