Develop Reference

Django Question - Should i start a new project in the same virtual environment?

Django newbie here.
I have an existing Django virtual environment that was setup as part of a tutorial,
using Django 2.2. and Vagrant + Virtual Box on my laptop.
There was 1 project created for the tutorial above.
I will now be starting another Django tutorial,
wherein I will be creating a few more projects.
WHat is the best way to go about this?
Should I create a new virtual environment for tutorial #2?
Or use the existing environment, that was setup for tutorial #1?
FYI - tutorial #2 uses Django 1.11
Thanks a lot!

It is always a good practice to create different virtual env for each django project. For example if you have multiple django projects that are using one virtualenv, and you want to host one of the django apps on a platform like Heroku which will require you create a requirements.txt file for python apps, so when you run pip freeze to get the requirements, you will find out that there are many packages in that env that is not required by your current project. And installing all those packages on your Heroku might make you run out of space before you know it. So try and keep the virtualenv different according to your project and keep the requirement.txt as well.

You have multiple options for package managers:
Pipenv
Poetry
Virtualenv
In general, Pipenv or Poetry are easier to use vs Virtualenv.
If you are still stuck, try using the Imagine smart compiler that handles your package installation as well as allow you to generate the code for your application logic.
Just do
npx imagine create -f Django -n myapp
make install && make run

Docker containers python environment vs python virtual environments

I program primarily in python and have some experience with virtual environments. I am new to the software and started looking at docker to run my code. I would like insight on what it does and how it works.
From my understanding docker containers are like virtual environments that run a set of instructions when executed and can treat that everything contained within it as a single entity (so it or something else wouldn't be conditional on each other?). As I read more about containers, they sound pretty perfect and would eliminate any need for virtual environments but again unsure. Would much appreciate some clarification on this because I haven't been able to find anything online.

The main purpose of the python virtual environment is the isolation of the environment for each project, it's mean that each project can have its own dependencies, regardless of what dependencies every other project has.
what-is-a-virtual-environment
But when it comes to docker, you can treat each docker image as an isolated environment, you do not need to create or maintain a virtual environment in Dockerfile, as Dockerfile should be base on a particular version of python and should run single project.
python-versions-docker
So in short, if you have 3 projects that require
Project A requires Python 3.6
Project B requires Python 3.7
Project C requires Python 3.8
All need to chose base image for each project
Project A FROM python:3.6
Project B FROM python:3.7
Project C FROM python:3.8

I prefer to think of containers as a OS on top of your OS. You can google lots of info about docker, but if talking in simple language it is a thin layer that runs on top of your OS, uses your OS's resources (unlike VM), and runs its own enclosed environment.

Not any of the two can replace the other. It depends on what you are doing.
Python virtual environment is a way to encapsulate all app dependencies inside a single environment (actually a directory). These dependencies are other apps and packages that support the OS version you are using.
Docker container is a way to run a virtual machine with low resource consumption by sharing a lot of your OS files (more details in docker docs)
So,
if you need to create a development environment; it is recommended to use docker because you can douplicate the exact development experience for all developpers. Everything will be in a virtual machine that has its own OS version and its own files (virtually). Python virtual envirounment will not 100% help other developers unless they are using the same OS version of yours and they can duplicate your exact steps to deploy your app
But, if you are creating a package that will deploy a remote server (let say by using ansible), docker will be an extra un-needed step. Python environment will do the job just fine without any issue.
Also, it is very common to have dockers that include many python virtual environments; one environment for each service. So, even a docker image can include a python venv

Create the Django app or the virtual environment first?

I have been trying to successfully create projects using Django however I have seen projects where the user will create the project first THEN the virtual env. I have also seen instances where the user creates the virtual env and THEN the django app. Both sides argue that their method is better, but now I am confused. Pls help

it is better to create the virtual environment first and start working in that environment. ie use python from that environment.
advantage:
a. environment will contain all the package required by the project
b. can switch between multiple env( testing purpose)
c. easy to keep a record of the required packages
d. will not affect another project where u need python 3.5 and in django project u require python 3.6
disadvantage:
need to keep track of each env in case if you have many virtual env ( all virtual env are store in same place just like anaconda one, else if store in project folder then no issue for1 env)

It depends on your usage.
Let's say you have Django 2.1 installed globally, then you have a project where you need let's say Django 1.9, here you need to set-up your virtual environment first

When you have a virtual environment you can track packages for each project.
When virtual environment is activated you can create requirements.txt file with command
pip freeze > requirements.txt
So when you want to run the django project to a different os you can install your packages from the requirements file you have created.
pip install -r requirements.txt
An other scenario is when your os has django 1.11 and you have a django project created with that version. When you upgrade the django version in your os the the django application will break.
So i think that for each django project a good way is to have its own virtual environment

How to change the interpreter of the project

I created a django project and its interpreter is an 3.5.2 ENV, all the extensions that I install in Pycharm it doesn't recognize them, when I try to add them in Installed APPS, they aren't available.
But if the interpreter is only python.exe it recognizes.
So, How do I change the intrepeter of a project that is set to the 3.5 2 ENV to another, I don't know exatly what ENV is, and why it doesn't allow me to use installed extensions.

Go to preferences then project. You can set the interpreter there.

I assume the ENV you are talking about is a virtual environment. You normally create your project inside a virtual environment in order to maintain project-specific dependencies. E.g. If you install a dependency in your virtual environment, it can be accessed ONLY from that container. So, it is not installed system-wide and therefore cannot be accessed by things outside of the ENV.
Makes sense because you don't really want to install project specific things system-wide. E.g. what if you wanted to work on one project with Django 1.10 and another with 1.8? You would create two virtualenvs to encapsulate each!
I know it doesn't answer your main question but it may help to understand what's going on.
https://virtualenv.pypa.io/en/stable/

Why is virtualenv necessary?

I am a beginner in Python.
I read virtualenv is preferred during Python project development.
I couldn't understand this point at all. Why is virtualenv preferred?

Virtualenv keeps your Python packages in a virtual environment localized to your project, instead of forcing you to install your packages system-wide.
There are a number of benefits to this,
the first and principle one is that you can have multiple virtulenvs, so you
can have multiple sets of packages that for different projects, even
if those sets of packages would normally conflict with one another.
For instance, if one project you are working on runs on Django 1.4
and another runs on Django 1.6, virtualenvs can keep those projects
fully separate so you can satisfy both requirements at once.
the second, make it easy for you to release your project with its own dependent
modules.Thus you can make it easy to create your requirements.txt
file.
the third, is that it allows you to switch to another installed python interpreter for that project*. Very useful (Think old 2.x scripts), but sadly not available in the now built-in venv.
Note that virtualenv is about "virtual environments" but is not the same as "virtualization" or "virtual machines" (this is confusing to some). For instance, VMWare is totally different from virtualenv.

A Virtual Environment, put simply, is an isolated working copy of Python which allows you to work on a specific project without worry of affecting other projects.
For example, you can work on a project which requires Django 1.3 while also maintaining a project which requires Django 1.0.

VirtualEnv helps you create a Local Environment(not System wide) Specific to the Project you are working upon.
Hence, As you start working on Multiple projects, your projects would have different Dependencies (e.g different Django versions) hence you would need a different virtual Environment for each Project. VirtualEnv does this for you.
As, you are using VirtualEnv.. Try VirtualEnvWrapper : https://pypi.python.org/pypi/virtualenvwrapper
It provides some utilities to create switch and remove virtualenvs easily, e.g:
mkvirtualenv <name>: To create a new Virtualenv
workon <name> : To use a specified virtualenv
and some others

Suppose you are working on multiple projects, one project requires certain version of python and other project requires some other version. In case you are not working on virtual environment both projects will access the same version installed in your machine locally which in case can give error for one.
While in case of virtual environment you are creating a new instance of your machine where you can store all the libraries, versions separately. Each time you can create a new virtual environment and work on it as a new one.

There is no real point to them in 2022, they are a mechanism to accomplish what C#, Java, Node, and many other ecosystems have done for years without virtual environments.
Projects need to be able to specify their package and interpreter dependencies in isolation from other projects. Virtual Environments are a fine but legacy solution to that issue. (Vs a config file which specifies interpreter version and local __pypackages__)
pep 582 aims to address this lack of functionality in the python ecosystem.