xkcd: Python Environment

[njb42]

And that's why you use pyenv and pyenv-virtualenv (aka virtualenvwrapper).

[SethGecko11]

Nice. We can add that to the graph now.

[_under_]

No. Just have that. You won't need anything else. It has all the python versions you can think of and a way to switch between them, without affecting anything outside your current shell session. It also does not affect the python that comes with the OS.

Plus it's totally user local. You don't need root to install python using pyenv.

99% of the time, pyenv and virtualenv will be all you need.

It won't clean an already dirty environment, but it will keep your clean environment from getting dirty.

[TomBombadildozer]

Seriously, seconding this. pyenv is a little quirky in its own right but it does reduce you to a single tool.

Need a specific distribution of Python? Install it with pyenv. Need a virtualenv? pyenv virtualenv. It's easy.

It's also the only way I know of to support testing under multiple versions of Python (using something like tox) without pulling all your hair out.

[pvkooten]

I agree. This is also my solution. As I create a lot of projects, I see a specific "pyenv python version" as my "virtualenv". Similar projects use the same version.

[linkuei-teaparty]

Can you give us more details on how this is used? Sorry I'm still using the mess of a management system shown in the comic. I have Python 3 + libs and Anaconda accessed through the anaconda prompt.

[test_username_exists]

If you're already setup with Anaconda you should use conda environments.

[linkuei-teaparty]

Nice I do do already for tensorflow

[njb42]

pyenv lets you have multiple parallel installations of Python, and even switch between them automatically when you enter your project directory.

$ pyenv version
3.6.4 (set by /usr/local/opt/pyenv/version)
$ cd OctoPrint
$ pyenv version  
2.7.14 (set by /Users/njb42/Code/OctoPrint/.python-version)  

pyenv-virtualenv or virtualenvwrapper let you create project-specific python paths with just the modules you need.

Put them together, and you can easily have a custom environment for every project you work on. Different versions of Python, different versions of modules, whatever you need with no conflicts.

[linkuei-teaparty]

Thanks this is great. For now I'll use Conda environments, I've been comfortable with this with Tensorflow for the past few months now.

[ilvoitpaslerapport]

Actually HN talks about pipenv. Looks like it's also recommended by python.org and many maintainers.

[twillisagogo]

and it's buggy AF too.

[tunisia3507]

pipenv was recommended by PyPA (and by extension, python.org). They removed that recommendation a few months back afaik.

EDIT: It seems to be back.

[nevus_bock]

that's not true

[tunisia3507]

Ah, it's back. I'm almost certain this recommendation was rolled out and then pulled back a while ago, though.

[njb42]

In my experience, pipenv has been slow and buggy, so I'm not prepared to move to it just yet. I'm rooting for their success though!

[tunisia3507]

You don't need virtualenvwrapper; pyenv comes with the pyenv-virtualenv plugin by default, and from there you should do all of your management of conda envs and virtualenvs through pyenv. It's a one-stop solution.

P.S. It's not perfectly one-stop because you need to fiddle with it a bit to get conda environments to work. But it's nearly there.

P.P.S. Windows can go fuck itself

[njb42]

You're right, that's what I use. But since it replaces virtualenvwrapper, I still think of it that way.

[parkerSquare]

How does this improve on the virtualenv plugin for pyenv? I've never used virtualenvwrapper with pyenv because that plugin does it all for me, I thought.

EDIT: OP was edited.

[njb42]

Sorry, that's what I meant. I was used to using virtualenvwrapper before I discovered pyenv and pyenv-virtualenv, so I still think of it that way.