Ok, you’ve touched on a number of different topics here.
First, I know it’s difficult, I made the same transition myself. But Python is not PHP and does not work like PHP. Do not rely upon your hard-earned PHP-knowledge. Try to start from a clean slate.
Simply as an issue of “mindset”, I would never put my Django projects in a directory named “www” or “htdocs” or anything directly related to a webserver’s directory. In a production-style environment, it’s not Apache or nginx running your application - there’s a layer in between. (See How to deploy Django | Django documentation | Django to start to get an understanding of the environment.) That Django provides a server for development purposes (
runserver) should not be interpreted as being representative of a deployment environment.
Second, and again it’s an issue of “mindset” and “terminology” to aid understanding, I would never say that a “project is inside their own environment”. Your project is run (usually) with a virtual environment “active”. The virtual environment being used may, but does not need to reside within your project directory. The physical location of the virtual environment has no bearing on the situation.
Having the virtual environment within the project directory, by itself, does not mean that that virtual environment is automatically use by your project, or that your project must use that virtual environment. Whatever virtual environment is “active” is the one your project will use. Placing the virtual environment within the project directory only facilitates some “administrative”-type issues, such as being able to include that virtual environment within your code checked into git.
The physical location of the virtual environment does not affect how your code is run.
So to give you an example, I have a directory named “work” off the root of my “E” drive. (
Within that directory, I have directories named
git, I might have
project_b - each of which being standard Django-organized projects.
ve, I might have directories
E:\work\ve\env_2) Each of those is a virtual environment.
To run either
project_b, I would activate either
In addition to those, I could also create a virtual environment within
project_a, and perhap call it
env_a. That actually adds a third option to both