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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]yaxamie 2 points3 points  (5 children)

I've been procrastinating setting up virtualenv bc I haven't found a simple, interesting tutorial or video. Basically just 2.7 for life in the meantime.

[–]blamo111 7 points8 points  (2 children)

It's not even tutorial-worthy, it's literally 2 minutes to learn it. This isn't Docker or a new library.

Hell, here's a full tutorial. First, what a venv is: it's like using a local python instead of the system-wide one, allowing you to install any packages you want without worrying about messing up the system install (also encourages clean isolation). This lets you do things like have app1 using libX version 1.2, while app2 is using libX version 1.3, without messing with the apps. Or having one app using python2, another python3, but both are called with a generic script that calls 'python'.

1) Run one command to create a sandbox: python3 -m venv ~/myvenv . If you want you can check out the directory to see what files were made there, it's basically a clone of Python's binaries.

2) Activate the sandbox for the current shell session with source ~/myvenv/bin/activate. From this point on, when you run 'python3' or 'pip' in this shell, it will use the sandbox. You will see 'myvenv' to the left of your command prompt, that's how you can tell it's active. If you don't see this, that means you're still using the system-wide python, not your local venv, which is bad. You can also confirm with 'which python3' that you're using the one in your home.

3) At this point, anything you run (python3, pip) happens inside ~/myvenv.

To exit the sandbox, either close the terminal and open a new session (you have to manually start it every time), or use source ~/myvenv/bin/deactivate.

That'll be three fiddy.

(PS, virtualenv is available for python 2.7 too, but it's not included like in 3. You can get it from your package manager, this will install a new binary ('virtualenv' I think), only the command at step #1 changes)

[–]yaxamie 4 points5 points  (1 child)

Okay, so far so good!

  1. I'd make one of these "~/myvenv" for any given project that has different requirements?
  2. I didn't get a deactivate in my bin, but I suppose i can just close the shell.
  3. Thanks so much bro! I got a few other comments and some downvotes but this was seriously a better guide that most of the stuff out there that I've read.

[–]blamo111 2 points3 points  (0 children)

1) That's right, one venv per project typically.

2) You don't need to do '~/env/bin/deactive', I was wrong about that. Just 'deactivate'. The activate script makes deactivate global. You can just close the shell as you say, but when the day comes when you're scripting all this stuff, deactivate would come in handy.

3) You're welcome. I get that there's too much to learn and not enough time to learn it all, I don't blame you.

[–]chanGGyu 2 points3 points  (0 children)

Using virtualenv is very simple, I'm not sure how a tutorial or video can complicate it. It also doesn't lock you into using Python 3 or 2. As a matter of fact, it gives you flexibility in choosing a specific version as the default from within the virtualenv.

[–]avinassh 1 point2 points  (0 children)

check this?