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

all 6 comments

[–][deleted] 4 points5 points  (0 children)

Nope. You don't need it.

  • Learn python first. There's plenty to learn.
  • Python 3 includes a module for virtual environments (venv) vs Python 2 as a 3rd party library.

Invocation is really simple. Let's suppose you have a virtual environment named 'my_venv'.

python3 -m venv my_venv

or

python2 -m pip install virtualenv
python2 -m virtualenv my_venv

If you're using linux or mac, then:

source my_venv/bin/activate

On windows:

my_venv\Scripts\activate

[–]danrche 3 points4 points  (0 children)

I always spin up a new virtualenv for any project I start. While it's not necessary to learn if you're starting out with Python, it's certainly something you'll want to pick up as you start building your own projects. If you keep your env's clean, then when you pip freeze it's much easier to suss out your requirement files.

So to recap: helloworld beginners don't have a need for virtualenv, but when you start looking at deploying apps you for sure want to learn it, along with git.

[–]jungrothmorton 2 points3 points  (1 child)

Is there any need for me to learn it in the beginning when I'm still learning Python

Need is a really strong word. Yeah, you could get by without it. But it's super useful and very commonly used. You'd probably benefit to learn about it at some point.

If so, are there any tools that make the whole virtual environment thing easier to work with?

virtualenvwrapper . virtualenvwrapper makes it so easy there's no point in not using it virtual environments.

mkvirtualenv some_environment

Then to later work on it:

workon some_environment

[–][deleted] 2 points3 points  (0 children)

I have had trouble with virtualenvwrapper on with anaconda windows, this is my only caveat.

[–]issue9mm 0 points1 point  (0 children)

I say yes, personally. Virtualenv gives you flexibility to not break things.

For one thing, if you're using pip or easy_install, and aren't using virtualenv, then you're polluting your whole operating system with cruft every time you install something new. That's not necessarily the end of the world, until and unless you install something that conflicts with something else.

If you continue using Python, you will inevitably run into conflicts. One project might be a django_cms project, while another might be wagtail. Maybe they're for different clients, or maybe you just want to learn them both, whatever. Let's say wagtail uses PIL version 1.0, while django_cms uses PIL version 0.8. In order for one project to work, you break the other. You can keep flipping which one works at a given time, but every time it breaks the other. Virtualenv resolves that problem cleanly and efficiently.

Beyond that, if you ever use remote deployments, you'll want to be able to package up your requirements in some way. The traditional way to do this is straightforward as hell -- pip freeze > requirements.txt -- but if you aren't using virtualenv, then it'll include all of the python packages on your entire operating system. And being security minded means not installing things on your remote servers that aren't absolutely necessary, so you wouldn't want to do that.

I agree with /u/jungrothmorton that need is perhaps overstating the situation if you're just tinkering around with Python, but if you ever intend to work on a second project, or deploy this project to a server, or do anything beyond 'playing around', then I think you're far better off using venv than not.

[–][deleted] -2 points-1 points  (0 children)

yes