I continue to experiment and try different things with Django, to better understand as much as I can. Yes, I’m spending a lot of time on this part of it, but I like to learn all the angles of something new. Anyway…
I have found two camps of thought when it comes to whether code should be inside the venv folder or outside.
It seems that most people say they should be separate, like this:
So… I tried doing them as separate folders like the first example, but then I got stumped when it came to activating the venv. To do that, I need to be in the venv folder, from what I understand. I’m basically activating the environment without it being associated with “project 1”. So how to do I accomplish that under this method? Or am I totally misunderstanding something here?
I’m on Windows 10, if that helps with a reply.
Thanks in advance!
In your “Scripts” directory within the virtual environment, you’ll find both an “activate.bat” (if you’re using the command prompt) and “Activate.ps1” for powershell.
You can run those from any directory to activate them. You do not need to have it as your current directory (or “being in it” as you’ve described it).
If you’re using VSCode, you can select the interpreter from within VSCode.
Okay, so here’s what I have:
While I’m in project1code, I want to activate the environment for that folder.
So I need to cd to project1env to get to the Scripts folder. But that means I’m no longer in project1code, because I’ve cd’d myself out of it.
So this leaves me unsure of how to activate the environment. …unless the goal is to activate it for the entire project1 folder and not just project1code?
This is not the right way to think about this. You do not activate an environment for a folder. You do not activate an environment for a project.
You activate a virtual environment for the OS shell in which you’re running. It has nothing to do with any project you are working on.
From the other conversation at https://forum.djangoproject.com/t/unclear-about-folder-structure-with-virtual-environment/11447/8:
… there is no structural file-system relationship between your Django project code and the virtual environment in which it runs.
Note: You can run a cmd file from any directory by specifying the full path to the script. You do not need to
cd into that directory. Likewise, once the environment has been activated for that shell, you do not need to keep that directory as your current directory. You can
cd to any directory and the environment will remain active.
I guess I’m just not grasping the concept well enough. I’ve read where venvs are good for when you have different versions of Python. This makes me think that a venv is for a specific project in those cases. That’s what I’ve been going for. I apologize for my ignorance.
No need to apologize - these may be some new concepts that take some time to wrap your head around.
Yes, venvs are good for when you want to use different versions of Python. They’re also good for when you want to use different versions of libraries in the same version of Python.
And yes, many people may associate a specific venv with a specific project - but that’s an administrative decision, not a technical one.
So perhaps you’re configuring your system to allow you to use both Python 3.8 and Python 3.9. When you activate an environment, perhaps the one for Python 3.8, you’re telling the operating system, that when you type the command
python -V, you want the operating system to use Python 3.8. Activate Python 3.9, and now you’re telling your operating system to make a different selection.
Note that none of this has anything to do with Django or any project you may be working on.
If you now issue the command
python manage.py runserver, the operating system is going to select the currently-active Python, and use it to run the
manage.py script. Notice in this case you’re not telling Python where to find manage.py - it’s going to assume that the file can be found in the current directory.
Change your current directory to a different project, and that same, active, Python environment is going to be used to run that other project.
Ah, a bit of clarity! Thank you!