Python has these things called virtual environments,
and it's really just a way for you to separate your code from
other code, which at first sounds a little confusing and
actually a little bit useless because we could just do that with folders.
But there is a reason we want to do this.
But actually, now that I think about it, there's a better
way to think about virtual environments.
It's like separating projects from other projects.
So let's say you are working for a web development agency,
and you have two projects.
You have a website that is using Django version 1.11, and
you have another website that's using Django version 3.0.5.
That was supposed to be a 3, 3.0.5.
Now, these are quite different.
It's the same framework, but there are a lot of differences,
and it's not just as easy as saying, "Hey, I want to use Django3
instead of Django1", and all of a sudden everything just works.
There are things you're going to have to change in your code.
Now, if this was the case, every time you switched projects,
you'd have to 'pip uninstall Django, and then you'd want to
'pip install Django' with the exact version that you want, which
is like 1.11; or if you were upgrading, 3.0. And
every time you switch projects, you'd have to do that.
Now, this is just one package, and this package has dependencies.
If we do 'pip show Django', we can see it's required by 'wagtail',
'treebeard', taggit', and 'django-debug-toolbar'.
That's all I have on my computer
anyways. There are a lot of other packages in the world that required Django.
So now let's say on the project that's using Django version
1, it's also using Wagtail CMS version 1.
But on Django version 3, the other project, it's using
Wagtail 2.9.
Now, again, Wagtail 1, and Wagtail 2 have their differences.
So that means you'd have to 'pip uninstall wagtail && pip install
wagtail=2.9'.
Now, okay, that's just two of these.
But what happens if you're using an old version of 'requests'?
'pip show requests'.
This is a very popular package.
What if you have an old package, or an old project that's
using 'Requests' version 1, and it's not compatible with 2?
Well, then again, 'pip uninstall requests && pip install
requests=1.', whatever that version is going to be.
[no audio]
And you're going to have to do that every single time
you change projects.
Now, that's not just for web development agencies.
That's also for any of your personal projects.
And that sucks to work with.
And there's a better way.
There's a thing called a 'virtual env', or a virtual environment.
With a virtual environment, you can have one project that
uses Django 1.11.
It could even, if you wanted it to, to use like Python 3.2.
Your virtual environments can be completely different from
other virtual environments.
So you can have a newer website that's using Django 3.0, and
also using Python 3.8.
And what a virtual environment does, is it lets you keep all
of your packages installed in one area where you can use
it, and then you can keep all your packages for another project
installed in another area where you can use those.
So because on one computer we can't have Django installed
twice, or any package installed twice
we have these things called virtual environments, where we
can have the package installed on one virtual environment,
and then have that same package, but a different version
installed in another virtual environment.
And the problem that this solves is versioning.
Now, if you're brand new to the idea of Python and virtual
environments, this is a life saving feature.
Now, there are two ways to use a virtual environment.
There's actually several ways, but we're going to cover two
ways. We've got one called a 'venv', and we have another one
called a 'pipenv'.
One is built-in with Python, and the other one is almost
built-in with Python.
So the one that's built-in with Python is the 'venv', and
you activate it, or you create one
rather. You create a 'venv', virtual environment with 'python -m
venv' is the command, and then you give it a folder.
So before I run that, let's run 'ls -la', and we can see the
only files that I have in here that start with a '.' is
'.DS_Store' because I'm on a Mac, and '.localized'.
What I can do is type 'python -m venv', and then a folder name.
So it could literally be 'anythingiwant',
and it's going to create a folder with my virtual environment
packages in there.
I'm going to name this '.venv', and it's just going to take a second.
And this is interesting.
I have the Python extension installed on VS Code, and I actually
noticed that there's a new virtual environment.
So that's pretty cool.
Not really related to this lesson, but still very interesting thing.
So now if I do 'ls -la', we have a folder in here called
'.venv', and I can 'cd' into that folder.
I can 'ls -la', or if you're on Windows, it's 'dir'. It's
'dir'. I've got a folder called 'lib', 'include', and 'bin', and I've
got a file called 'pyvenv.cfg'. So I'm going to actually go up one directory.
We don't really ever need to go into that directory, unless,
of course, you need to edit some source code.
Now, whenever you do 'pip install', some package name,
the idea is to make sure that it's inside of this 'venv'.
Right now it's on our entire computer.
It's not inside this virtual environment.
So we have this virtual environment installed in this folder
called 'venv' or '.venv', and we need to get inside of this virtual
environment, and you can think of this as an abstract
layer away from your computer.
So what I can do here is type 'source .venv',
that's the folder name that I gave it.
'/bin/activate'.
Now, this is weird.
This is probably one of the weirdest things you're going to see
in Python, but I promise you'll get used to that one.
And now you can see I'm actually inside of the virtual environment.
It says '.venv'.
And if I do, just for fun,
'pip freeze'.
There's nothing in there.
There are no packages in here.
And if I want to get outside of my virtual environment,
I type the word 'deactivate', and it gets out of it.
And if I do 'pip freeze', watch this,
if I can spell it right, third time is the charm.
Okay, so I did 'pip freeze'. I'm on my computer.
I'm not inside of my virtual environment.
These are all the packages that I have on my computer right
now. But when I go back into my virtual environment, and type
'pip freeze', nothing shows up.
This is a brand new slate.
There is nothing in here.
And so just for fun, let's go ahead and do a thing.
Let's 'pip install' a different version of Wagtail.
'pip install wagtail',
and let's do wagtail2.1.
[no audio]
So for some reason, I want to install an older version of
Wagtail CMS, and it's going to go and install a bunch of
stuff. It has dependencies in there.
So it's going to try to install all sorts of things.
We can see it's actually installing all sorts of things in
here. And now let's run 'pip freeze' inside the virtual environment.
Look at all these packages that I have now, and I have Wagtail2.1.
So now let's 'deactivate' this, and do 'pip freeze |
grep wagtail'.
And all I want to do is get that list of all my packages
that I have on my computer because I'm outside of my virtual
environment, and I'm simply running a Unix command called
'grep', and I'm looking for a keyword called 'wagtail'.
And I'm going to show you that I'm not using Wagtail 2.1
anymore. On my computer, I'm using Wagtail 2.7.
And if I go back into my virtual environment, and run the
exact same code, I'm using Wagtail 2.1.
So on my computer, I have 2.7, which is outside of my virtual
environments, but inside of this virtual environment, I have
Wagtail 2.1.
And so now I can use different versions.
I'm not going to run into problems. I don't have to
'pip uninstall wagtail 2.7 && pip install wagtail 2.1' every
single time I switch a project, it just keeps it in there for me.
Now, that is one method.
And to deactivate, you just type 'deactivate'. That gets you
back on your computer, and outside of your virtual environment.
'ls -la' or 'dir'
if you're on Windows. If you ever wanted to delete this virtual
environment, this is literally just a folder, you could delete
this very easily.
And so I can open up my Desktop in my Explorer, or in Finder,
or in Nautilus, whatever version you're using on your operating
system. I use a Mac, so it's called Finder.
You could just open that up, and you could find this folder
and delete it, or you can do it from the command line.
I'm going to show you the command.
Please be careful with this.
Do not run this unless you absolutely know what you're doing.
'rm - rf .venv', this is going to remove, this is going to forcefully
remove a folder, and I'm going to pass in the folder name,
and that's just this one.
If you cause a typo here, you could end up deleting a lot
of stuff off of your computer permanently.
So only do this if you are absolutely sure what you're doing.
Otherwise, go through Finder, go through Nautilus,
go through Explorer,
go through some visual tool if you can.
So I'm going to just delete this, 'ls -la', and my virtual environment
is gone.
The second method is with a thing called a 'pipenv', and I'm saying 'pipenv'
Let's use 'figlet' here, 'pipenv'.
Now, 'pipenv' is arguably an easier way to create a virtual
environment. It's a newer way, and it actually requires you
to 'pip install pipenv'.
[no audio]
There we go. 'pip show pipenv'.
Cool beans.
I am now using 'pipenv', and I can create a new virtual environment
with this keyword, 'pipenv', and I can run 'pipenv --help',
and we can see a bunch of commands in here.
We can check clean, install, graph, lock, open, run shell,
sync, uninstall and update. 'uninstall' and 'install' are two that
you're definitely going to want to use.
So instead of using 'pip install', you would use 'pipenv install',
and then the package name.
Now, if you want to create a new virtual environment with
'pipenv', it's as simple as saying 'pipenv install'.
The nice thing about 'pipenv', is you can actually tell it which
version of Python to use as well.
Now, if I want to get inside of the 'pipenv', I can simply do
'pipenv shell', which is what it's telling me to do.
Or if I want to run a command from my computer without being
inside the virtual env, I can run 'pipenv run', and then a command.
So let's go inside here, and you can see this one's going
to look a little different.
And this one says '(kalobtaulien) bash'.
So just do 'python -V', still using the same version of Python. That's good.
And now I can do 'pip freeze', and there's nothing in there.
And you can still use 'pip' inside of 'pipenv' if you want to.
And to get out of this, we don't use the 'deactivate' keyword,
we hit 'Control + D', and that exits for us.
Now to install, we could do 'pipenv install',
let's say 'Django==3.0.5', and it's going to go ahead
and install Django3.0.5.
Now one of the downsides to using 'pipenv', is it does come with
nice, easy commands to use, but it also takes a little while.
So that took, I think, a little longer than it usually would
have to install Django.
And now we can activate this with 'pipenv shell'.
That's just going to get inside of our environment.
We already created it.
All we have to do is get inside of it, and we can do a 'pip
freeze'. 'pip freeze'.
And we will now see that.
Hey, look at that.
Django, asgiref, pytz, and sqlparse are all installed
now. Now, to get out, again, that's 'Control + D'.
And if you wanted to delete your 'pipenv', you could simply do
'pipenv --rm', or let's do 'pipenv --help',
[no audio]
and does that mention anything in here?
[Humming]
Yeah, here we go to, "Remove project virtualenv', and we can simply
run 'pipenv --rm'.
So 'pipenv --rm', and it's deleting all those files for me.
So now, moving forward, all of your projects, everything
you do in Python should ideally be in some sort of virtual
environment. It doesn't matter if you use 'pipenv',
it doesn't matter if you use 'venv',
you could even use Docker, or Vagrant, or some sort of
abstraction layer like that.
As long as you have a virtual environment that's somewhat
separated from the rest of your computer, that is a good way to go.
[no audio]