On Thu, Jan 18, 2018 at 10:13 PM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote:
> PS - this is the pyenv / tox compatibility issue I had in mind: > https://github.com/pyenv/pyenv-virtualenv/issues/202 > > And this I have found is the simplest workaround: > https://github.com/pyenv/pyenv-virtualenv/issues/202# > issuecomment-284728205 I find it simpler if you just define multiple pythons in a project specific .python-version for pyenv as it simply injects them into your path-esque shim resolving mechanism in order. The content of one example .python-version of mine: 2.7.14 2.7.14/envs/detox 3.4.7 3.5.4 3.6.4 This way the python2.7 tox finds first is the one from the clean one and thus creates a clean functional virtualenv from it, likewise for the Python 3 variants. The detox virtualenv is there so the pyenv provided shim for tox/detox resolves to that as the first hit. I like for my tox tests to run in parallel, but this also works for just plain tox (and then you can choose for which Python version you want to install tox - detox is Python 2.7 only for now). The detox virtualenv can be initially created via pyenv virtualenv 2.7.14 detox. Then I usually pyenv shell 2.7.14/envs/detox and pip install detox. Or this can also be done via a requirements file, if a project pins it for reproducibility, in which case I'll probably create a project specific detox/tox virtualenv via pyenv and add that to the project .python-versions file, thus fully isolating things from each other and having everything pinned with explicit configuration per project. And I usually also have a separate 3.6.4/envs/projectname for actually running the project / for interactive work with the project I enable via pyenv shell 3.6.4/envs/projectname. To me this seems the intended way to use pyenv - relying on its core mechanisms instead of piling up layers of workarounds. A simpler setup might be: 3.6.4 3.6.4/envs/projectname 3.5.4 3.4.7 2.7.14 But one needs to remember to pyenv shell 3.6.4/envs/projectname in order to pip install anything to the correct environment as pip3.6 would resolve to the global one (and one should try to keep that in pristine if trying to do things this way, even if the point of virtualenv is to isolate you from the system site-packages). At least the way pyenv modifies the shell prompt keeps things helpful enough for me to get by, but it is one more layer to keep track of. -- Joni Orponen
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
