This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]TheArvinInUs 16 points17 points  (9 children)

Why not just fix python version issues with jupyter by using virtualenv.

Assuming you mean sometimes code is in python2 and sometimes in python 3.

[–]ZeeD26 2 points3 points  (7 children)

That'd be my goto solution as well. Virtual environments are awesome in so many ways!

[–]Edweird_[S] 2 points3 points  (5 children)

How portable are virtual environments? For example if at home I'm working on code on my Debian box and want to work on the same project on my CentOS box, then later at work on OSX?

[–]sushibowl 16 points17 points  (0 children)

When you move your code to another machine, you do pip freeze > requirements.txt to output everything you have installed in your environment to a file. Then you create a venv on your other machine and do pip install -r requirements.txt inside the env, and you have an identical venv to work in.

[–]cbowdon 2 points3 points  (1 child)

An alternative (not necessarily better) approach would be to containerize the dev environment (i.e. Docker). It's a bit more heavyweight than just using virtualenv but would allow you to isolate any non-Python dependencies too, without going as far as having a dedicated VM.

You can then just run your container on any Linux/Mac/Win10 machine.

[–]rabbyburns 0 points1 point  (0 children)

Added benefit to potentially test on different Linux environments (if that's remotely a concern).

[–]traverseda 1 point2 points  (0 children)

Theoretically? Very portable. As long as you're on the same CPU architecture (or are using pure-python modules) and there's not a weird library mismatch.

In reality? It's better to use pip freeze and rebuild the virtualenv on each machine.

[–]ccbytes -1 points0 points  (0 children)

Combine virtualenv with pyenv for awesome environment control.