# Best practice for venv vs code? **URL:** \ **Category:** Getting Started\ **Created:** [February 9, 2022, 12:36am UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049 "2022-02-09T00:36:33Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![CBIweb](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/cbiweb/32/6893_2.png) [@CBIweb](https://forum.djangoproject.com/u/CBIweb)\ **Post date:** [February 9, 2022, 12:36am UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/1 "2022-02-09T00:36:33Z")
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: **projects** – venv – project1 rather than **projects** – venv ---- project1 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! ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [February 9, 2022, 12:41am UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/2 "2022-02-09T00:41:29Z")
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. ---
**Author:** ![CBIweb](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/cbiweb/32/6893_2.png) [@CBIweb](https://forum.djangoproject.com/u/CBIweb)\ **Post date:** [February 9, 2022, 3:33pm UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/3 "2022-02-09T15:33:28Z")
Okay, so here’s what I have: **project1** — project1code — project1env 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_? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [February 9, 2022, 4:59pm UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/4 "2022-02-09T16:59:10Z")
> [@CBIweb](#): > > I want to activate the environment for that folder. 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:](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. ---
**Author:** ![CBIweb](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/cbiweb/32/6893_2.png) [@CBIweb](https://forum.djangoproject.com/u/CBIweb)\ **Post date:** [February 9, 2022, 6:50pm UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/5 "2022-02-09T18:50:46Z")
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. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [February 9, 2022, 7:10pm UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/6 "2022-02-09T19:10:23Z")
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. ---
**Author:** ![CBIweb](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/cbiweb/32/6893_2.png) [@CBIweb](https://forum.djangoproject.com/u/CBIweb)\ **Post date:** [February 9, 2022, 7:17pm UTC](https://forum.djangoproject.com/t/best-practice-for-venv-vs-code/12049/7 "2022-02-09T19:17:26Z")
Ah, a bit of clarity! Thank you!