Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Python Virtualenv

Michal Janek
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Michal Janek
Front End Web Development Techdegree Graduate 30,654 Points

Virtualenv for different Python Versions

I am a little bit unsure about the concept of using different Python Versions. Kenneth said at the beginning that in case something runs on Django. 1.8 and you want to make another project running Django. 1.9 but do not want to upgrade the first one you do a separate env.

But that is with Django versions or any other modules. What about different versions of Python. Is there a quick summary how to use two or more python versions simultaneously (Not at the same time of course but having them installed) without messing things up using venv? (or even without venv although it is slightly out of topic).

Thanks if anyone knows.

1 Answer

Chris Freeman
MOD
Chris Freeman
Treehouse Moderator 68,423 Points

Virtualenv provides two main features: Temporary alter system executable Path to place preferred version ahead of other potentially found on the system; and a venv-specific place to store executable files so that they can not be seen by other programs.

To specify a unique version of Python in an venv, use the -p switch. Give full paths if version not currently on system Path.

# with virtualenv:
virtualenv -p /usr/bin/python3.5 venv35
virtualenv -p /usr/bin/python3.6 venv36

# with virtualenvwrapper
mkvirtualenv -p python3.5 <name_of_env>

Personally, I prefer mkvirtualenv because it centralizes all the venv directories in one place where any one can be activated from practically anywhere.