Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Isolating Dependencies With Virtual Environments
00:00 In this part of the course, you’ll learn how to isolate your Python dependencies using so called virtual environments. Here is where you are right now in the course.
00:11 And this is what you are going to cover in the upcoming module in the course. You are going to learn about virtual environments, what they are, how they work, and what they are good for.
00:23 Next, you are going to learn how to create and activate a virtual environment on your system, after that, you’re going to learn how to install packages into a virtual environment; you’ll also learn how to deactivate virtual environments and how to completely delete them again.
00:39 And last, I am going to show you some tips in my personal workflow that I use to make working with virtual environments a little bit more efficient. Okay, ready? Let’s jump right in!
00:49 So we just learned that Python has a powerful package management system. What do we need that isolation for? The thing is that by default, pip installs all packages in a single shared environment, which means that if you need different versions of Python packages, there are going to be version conflicts.
01:08 Here is an example. Imagine you are working on two projects. Project #1 needs a specific version of Django, let’s say version 1.8, and it also needs a specific version of the Requests library, let’s say version 2.0.
01:22 Now, the other project, Project #2, needs a completely different version of Django, and it also needs a different version of Requests. Now if all of your packages need to be installed into the same shared environment, there are going to be version conflicts between these packages.
01:40 Another kind of version conflict you might face is that let’s say you are working on one project that actually needs Python 2.7 to run, and all of your new development happens in Python 3.
01:52 So, maybe you’re working on another project that actually requires Python 3.6 to run. How do you resolve these version conflicts? Virtual environments are really helpful tool that can help you with this problem, so a virtual environment allows you to isolate all of your Python dependencies by project, and this works for packages and also for different versions of the Python interpreter.
02:18 So you can think of these virtual environments as individual sandboxes for each project.
Dan Bader RP Team on Sept. 17, 2019
Hi aravind, check out these three courses:
- Test-Driven Development With PyTest
- Writing Cleaner Python Code With PyLint
- Continuous Integration With Python
I also recommend that you take a look at this learning path:
aravind on Sept. 18, 2019
Hi Dan, thanks. I will go through the links.
Meanwhile, do you have a video or upcoming course on “TOX”? I think its tox.readthedocs.io/en/latest/. * Tox vs. PyTest * When to use which * Pros/Cons of each * Sample test cases using Tox
Dan Bader RP Team on Sept. 18, 2019
Yep, we do have a Python testing tutorial on tox. pytest and tox do two completely different things, so it’s not really a “pytest vs tox” question IMO. But you’ll hear all about it in the tutorial I linked above :)
aravind on Sept. 19, 2019
Fantastic, Dan - really loving the courses on this website and also the support in the comments/forums - keep up the great work & looking forward to purchasing further courses!
Bobby Tagget on Oct. 28, 2023
Why can’t we just always make sure we are keeping our software versions up to date instead of using virtual environments?
The only reason I can think of, is that, we can’t be sure that the latest version of a package won’t break our software.
I would really appreciate input into this because I have very little confidence in the efficiency of virtual environments.
Bartosz Zaczyński RP Team on Oct. 30, 2023
@Bobby Tagget When you work on a single hobby project where you’re the only developer, then using virtual environments can indeed seem redundant because you generally want to use the latest versions of your dependencies. However, virtual environments help solve problems that may arise when you work on multiple projects simultaneously or if you’re a member of a larger team.
More specifically, different projects often depend on different versions of the same library. Without isolated virtual environments per project, this could lead to version conflicts, informally known as dependency hell. The larger your project, the bigger of a problem this becomes because it’s more likely to have a conflict.
Other than that, virtual environments ensure reproducibility, which helps other team members work on exactly the same library versions as yours. When deploying your project to a remote environment, you also want it to use the expected library versions as opposed to whatever comes installed on that machine.
Become a Member to join the conversation.
aravind on Sept. 17, 2019
Hi Dan, do you have any other courses where i can learn about pylint and pytest (writing and executing unit tests) and integrating these in a CI pipeline?