Clarify how to manage conda environments with older Python versions

[astrojuanlu]

Right now pyenv allows installing miniconda and miniconda3, which assumes latest Python 2 (2.7.13) and Python 3 (3.6.2 at the time of writing). However, it is not clear what is the preferred way to manage conda environments that make use of older Python versions, for instance a conda environment with Python 3.5.

[jimmywan]

I don't think there's anything that needs to be done. It just works.

before

$ pyenv shell miniconda3-4.1.11/envs/test
(test) (test) ✔ 17:48[vagrant@ubuntu-14:~] $ python --version
Python 3.6.2 :: Continuum Analytics, Inc.

change python

(test) (test) ✔ 17:48[vagrant@ubuntu-14:~] $ conda install python==3.5
Fetching package metadata .........
Solving package specifications: .

Package plan for installation in environment /home/vagrant/.pyenv/versions/miniconda3-4.1.11/envs/test:

The following packages will be UPDATED:

    pip:        9.0.1-py36_1  --> 9.0.1-py35_1
    setuptools: 27.2.0-py36_0 --> 27.2.0-py35_0
    wheel:      0.29.0-py36_0 --> 0.29.0-py35_0

The following packages will be DOWNGRADED due to dependency conflicts:

    python:     3.6.2-0       --> 3.5.0-1
    xz:         5.2.3-0       --> 5.0.5-1

Proceed ([y]/n)? y

after

(test) (test) ✔ 17:48[vagrant@ubuntu-14:~] $ python --version
Python 3.5.0 :: Continuum Analytics, Inc.

[astrojuanlu]

I don't think there's anything that needs to be done. It just works.

My point here is that this is not the typical conda usage. I have been using it since the beginning and never changed the Python version of an environment - it might be a personal thing of course, but perhaps adding this bit to the docs would ease adoption.

[jimmywan]

My point here is that this is not the typical conda usage.

I don't think that's a true statement, I do it all the time and conda allows you to seamlessly upgrade/downgrade.

I have been using it since the beginning and never changed the Python version of an environment

I think that's more of a "you" thing than a "conda" thing.

This entire topic is also more of a conda thing than a pyenv thing. ¯_(ツ)_/¯

I'll let the mods decide.

[astrojuanlu]

I think that's more of a "you" thing than a "conda" thing.

Fair enough, point taken.

[clbarnes]

Related to this, conda2 and conda3 can both make python environments in python versions 2 and 3; both seem to default to py3.6. It would be helpful to be able to add arguments to pyenv virtualenv and pass them through to virtualenv/ conda env so that we could do pyenv virtualenv miniconda3-latest my-env python=2.7. Obviously it's possible to just activate the environment and change it there but it's not ideal or documented.

[danieltomasz]

many years later this is not solved unfortunately; Readme claims about passing arguments but specyfing older python doesn’t seems to work

[native-api]

There's *conda*-latest if you want a rolling-release model and *conda*-<version> that's supposed to be used to get specific conda releases.

Each conda release ships with a specific release of Python, so if you need multiple, you are supposed to either install multiple conda releases with corresponding versions of Python, or create multiple conda environments with different python packages or something if conda allows that.

We offered to disallow changing the version of conda in release-specific conda installations during conda package updates, and that idea was rejected by the affected user, see https://github.com/pyenv/pyenv/pull/2094 .

[danieltomasz]

I ended up with a "ugly" makefile hack

install:
    $(eval PYTHON_DIST := miniforge3-latest)
    $(eval CONDA_BIN := ~/.pyenv/versions/${PYTHON_DIST}/bin/conda)
    $(eval PYTHON := ~/.pyenv/versions/${VENV}/bin/python)
    @echo "Installing $(VENV) with $(PYTHON_DIST)"
    env PYTHON_CONFIGURE_OPTS=--enable-shared pyenv install --skip-existing ${PYTHON_DIST}
    ${CONDA_BIN} update -n base -c conda-forge conda
    pyenv uninstall ${VENV} || true
    pyenv virtualenv  ${PYTHON_DIST} ${VENV} || true;
    ${CONDA_BIN} config --env --set channel_priority strict &&\
    ${CONDA_BIN}  env update --name ${VENV}  --file local.yml --prune -v

I first create new default virtualenv, and then reinstall all packages on the basis of local.yml, I didn't find the way how to pass local.yml to pyenv virtualenv

VENV is a global name of the env that I use in other recipes too.

[native-api]

I didn't find the way how to pass local.yml to pyenv virtualenv

pyenv virtualenv can pass arbitrary long options to the underlying program -- but only long options (arguments starting with --):

$ pyenv virtualenv --help                             
Usage: pyenv virtualenv [-f|--force] [VIRTUALENV_OPTIONS] [version] <virtualenv-name>
<...>

So the way to pass "--file FILE" is via --file=FILE if conda supports this form.