As I approach example 46, I am wondering what is the purpose of a virtual environment and why is Linux/Ubuntu run on it? Why can’t the virtual environment just run on another version of windows?
I don’t really understand your question. Are you talking about a virtual environment for running python in, or a virtual machine that runs Linux?
The former is a container that you can install python specific libraries and python version software in so you have a partitioned workspace for a project. Because tools like virtualenv create small virtual environments, you can have on in your project location and manage all your dependencies in that location. This makes shipping the project efficient and allows you to have lots of different setups depending on what you are doing.
As an example, I have python virtual environments each with a different version of python from 3.6 to 3.9. I also have some project specific ones for Django or Flask projects with their respective libraries and additions. It keeps it all tidy.
The latter, a virtual machine is just that. It’s also a container that installs an entire operating system in. Tools like virtualbox allow you to allocate some of you disk space, memory and cpu allocation and install any OS into that space. So I’ve had windows machines with a Linux VM, or my Mac’s running Windows in a VM. Because resources are shared the VM tends to be slower.
Does this help?
2 Likes
Just as a complement to @gpkesley’s answer:
With the advent of cloud computing, the concept of containerization, that is, of packaging an app together with a bare minimum of dependencies so it can be run anywhere with no hassle, has become very important. These days you just write your web app with any tech stack you like, put it in a docker container and push that to some server, and because the docker image has everything your app needs to run, you have very little setup and maintenance overhead as far as the server is concerned.
But as Graham says, Python virtual environments don’t go that far. They’re just a way to keep your working environments cleanly separated.
Sure, you can run Windows on a virtual machine. But if you already are on a Windows host, there’s no reason to do so. You use VMs precisely to get an environment different from the one you usually have. Linux has a tradition of being “the developer’s OS” (maybe they like that they can break it so easily). Also, the large majority of servers run Linux, so it kinda makes sense to create stuff in the environment where it will be run eventually.
If you ever need a Linux VM on a Windows host, I strongly encourage you to check out the Windows Subsystem for Linux (WSL). That is now a much better solution than spinning up a full blown VM, because it’s closely integrated into the main OS, with shared resources etc.
1 Like
Thanks, these responses helped a bit, but why would you want multiple versions of Python? Couldn’t you just have the most updated version on your home directory instead of using older versions? Or does it interfere with the different versions of the modules installed?
It’s more about different versions of libraries that you use in different projects.
Imagine you have a project P1 that uses library L in version 1. Then L is updated to version 2, but the new API is not backwards compatible and you don’t want or can’t update P1, so you keep using L v1.
Now you create a new project P2 where you also need L, but of course you want to use the newest version, L v2. Now what version of L should you install in your environment to keep both projects working?
Enter virtualenv to save the day… you create a separate environment for each project, install the appropriate version of L in each of them and because they don’t interfer or otherwise talk to each other at all, everybody lives happily ever after.
This may seem a bit unnecessary at the moment, but when you work in a professionel context in an ecosystem that is as unstable as pip (or npm or whatever) you must to be able to freeze dependency versions, otherwise you can’t guarantee that your software will keep working.
1 Like