I want to build a ‘website’ from scratch and wondering how to setup a new project.
So on my computer I have a folder named “Django” this is where I want to store all projects. In this folder, I have included a virtual env (“env”). See picture below.
Question regarding the above notes:
- Should I make for every ‘new’ project a virtual environment?
- If the virtual environment is OK from the above question, is the correct way to start a new project as follows:
- In the command Prompt:
(env) C:\Users\Lenovo\Documents\Django>django-admin startproject mysite
Now I have created a new site, right?
- Make a new virtual environment per project?
- Opinions differ on this. There are a number of people here who will advocate creating a venv for each project, and making that venv part of the project directory structure. I understand their reasoning behind it. It prevents a number of potential problems by including all the code you’re going to need in what you might consider your “deployment package” to be. (I believe they also include that venv as part of the repo for that project, keeping everything together.)
However, while I acknowledge all that and do see the value, I must admit that I don’t work that way. I create one venv for each deployment target (server) which is going to run the project.
I’d say, go with whatever works for you.
- Yes, that’s the basic, most simple way to start a project.
I wouldn’t say you’ve created a new “site”, because at this point you don’t have any views to generate responses, or urls to map requests to views, or models to define data. You also only have the skeleton of a settings file - something you can use to get started from. So what you’ve got is a directory structure and some blank files, but that’s about it.
What you can do from that point is to go into that directory, run
python manage.py migrate to establish your initial data.
Then you can do a
python manage.py runserver, which starts the test server. Pointing your browser at that location will show you the welcome screen.
Thanks again for the explanation Ken.
What do you mean with “deployment target (server)”? It runs the project, but does it mean that is run all the projects located at the current folder of your computer?
I run multiple projects on a variety of servers. It’s not effective for me to create a venv for each project and manage them all across all the devices being used as servers. So my work environment is such that I create one venv for each server that is going to run one (or more) different Django (and non-Django) projects.
Looking at it a slightly different way:
Server A, running venv “a”, might run project “X” and “Y”.
Server B, running venv “b”, might run project “Y” and “Z”.
This means that Project Y has to run in both venv “a” and “b”, and so in development and testing I need to run it in both to ensure I have all the appropriate libraries in each.
(Yes, each project is a complete Django project started from a
Okay this makes sense. Just as a point of interest, how do you run two venv at this same time? If you want to run project Y. Is this actually possible in the cmd prompt?
I don’t - at least not in the same session. In practice, one of the venvs is “primary”, the other is a “secondary” configuration. What I really do is all my development on the first, then run my tests on the second to ensure I didn’t break anything - or to find out if I need to update something. If I really wanted to run it in both at the same time, I’d open up a second terminal session and activate the other venv in that second session.
Hmm ok, this goes a little to deep for me
I have another question, again .
What is the actual function of a . (dot) in django? And is it necessary to import views? Because the views.py in already in the same directory right?
from django.urls import path
from . import views
urlpatterns = [
path('', views.index, name='index'),
from . import views is the Python mechanism for importing the views file into the current module.
. does specify that you’re importing this from the same directory, which in Django terms is usually an app. This is to distinguish it from (possibly) importing the views from a different app.
You need to import this file, otherwise this file isn’t going to have any access to the function named ‘index’ in the views.py file.
Keep in mind that you’re not just running this file - this is just one module in a much larger system, and your “current directory” is not the same directory in which this file resides.
Ok, but to have it clear. What is then the function of the . (dot) in the views.index in the path()? Because I already imported the views.py ??
In this case, the ‘.’ is saying “from the same directory as the urls file, import the views file.” From there, you can use views.FUNCTION_NAME to access any function inside the views file.
To expand a little on @Suttonium’s answer - What you have done with the line
from . import views
is import views.py as a module named views.
(I’m being a little sloppy with my terminology here. I’m not being 100% precisely accurate - but it’s close enough for this discussion.)
So, when you want to use something within that module, you need to reference it through the module name.
In this case, there’s a function named
index defined in that file. Since the module is named views, a reference to that function would be
This is different from just saying
because that would import the function named
index into the current namespace. Not a good thing if you have two different functions named
index in two different modules and tried to import both modules into your current namespace.
Also be aware that you can change the name of a module when importing it using the
as clause on the import.
Let’s say that for whatever reason, you have three views all named
index in three different
views.py files in three different directories, but you want them all accessible at the same level URL level as
urls.py file could look like this:
from django.urls import path
from app1 import views as views1
from app2 import views as views2
from app3 import views as views3
urlpatterns = [
path('index-1', views1.index, name='index1'),
path('index-2', views2.index, name='index2'),
path('index-3', views3.index, name='index3'),
(Now, I’m not saying you would ever really want to do this. This is just an illustrative example of using module imports to keep function namespaces separated.)
Thank you both for your help and explanations. I think I get it now :).
I have now in mind,
- Module is a ‘seperate’ file of code which can be invoked to avoid having iterations
- A module is included with functions (for example
But in addition to this topic, what is the difference between
models.py are meanly included with
classes instead of
From the appropriate Python docs:
A module is a file containing Python definitions and statements.
A module can contain executable statements as well as function definitions.
A module can also contain class definitions.
That’s standard Python, and if you’re not familiar with this concept, it would be worth your time and effort to work through some Python tutorials on this topic.
A Django Model is a Python class that Django uses to map a database table to a Python object. Django models are traditionally stored in files named
You should think of models as the core objects of your application. The models are the represantations of the things that your app will work with. Pretty much everything else is a layer on top of the models. Views display models using templates. Forms are ways for users to interact with the models. The urls file “allocates” the views within your site.
Models are classes and have functions. Views can be either classes or functions. When you use views as classes, there is a routine of associated functions that is called. Forms are classes that have functions. The urls file uses functions to work with view classes or functions that you defined earlier.
Thanks Ken and Spidiffpaffpuff,
Two things which where very helpful for me in this case:
And yes, I am learning python in addition with books. But this is actually my first practical exercise where I can find out how these things work in ‘real life’