Django syntax

[mepyyeti]

So I'm getting used to the Django framework and sort of bouncing from videos/books. No two materials seem to use the same syntax. I'm trying to understand why I'm typing what I am into the terminal instead of just typing (ie django-admin.py manage.py migrate before python3 manage.py run server ...I want to understand why it's django-admin.py in one area and python3 in the another). So I have a question. The following works on local host.

So mainly what is the difference between these two "styles"? (I don't have a better word).
Also The first example tells me that I must use (dot) when starting project. The second example ignores it...

Can anyone PLEASE run through these quickly? they both work in my browser...but I just want to understand...

[inline]me@me-ubuntu:~/Desktop$ mkdir foo
me@me-ubuntu:~/Desktop$ cd foo
me@me-ubuntu:~/Desktop/foo$ python3 -m venv foo_env
me@me-ubuntu:~/Desktop/foo$ source foo_env/bin/activate
(foo_env) me@me-ubuntu:~/Desktop/foo$ pip3 install Django
--SNIP--
(foo_env) me@me-ubuntu:~/Desktop/foo$ django-admin.py startproject foo .
(foo_env) me@me-ubuntu:~/Desktop/foo$ python3 manage.py migrate
--SNIP--
(foo_env) me@me-ubuntu:~/Desktop/foo$ python3 manage.py runserver
Performing system checks...
--SNIP--
Quit the server with CONTROL-C.
[/inline]

ANOTHER STYLE
[inline]me@me-ubuntu:~/Desktop$ mkdir foo
me@me-ubuntu:~/Desktop$ cd foo
me@me-ubuntu:~/Desktop/foo$ virtualenv foo #this part here is different with VIRTUALENV
Using base prefix '/usr'
New python executable in /home/me/Desktop/foo/foo/bin/python3
Also creating executable in /home/me/Desktop/foo/foo/bin/python
Installing setuptools, pip, wheel...done.
me@me-ubuntu:~/Desktop/foo$ cd foo
me@me-ubuntu:~/Desktop/foo/foo$ source bin/activate #this is also different involving wheels (~tarballs?)
(foo) me@me-ubuntu:~/Desktop/foo/foo$ pip3 install django
--SNIP--
(foo) me@me-ubuntu:~/Desktop/foo/foo$ django-admin startproject foo #no \s dot ? why?
(foo) me@me-ubuntu:~/Desktop/foo/foo$ cd foo
(foo) me@me-ubuntu:~/Desktop/foo/foo/foo$ python3 manage.py migrate
--SNIP--
(foo) me@me-ubuntu:~/Desktop/foo/foo/foo$ python3 manage.py runserver
--SNIP--
[/inline]

[knackwurstbagel]

These are my observations if anyone knows better or see any mistakes please correct me and I will make the edits. I do not wish to mislead. There are a lot of resources online that describe what is happening but these are my two cents.

In the first example you are using python3 -m venv, vs the second example of using virtualenv. This should answer the question of what the differences are https://stackoverflow.com/questions/4157...e#41573588 the author Flimm goes into nice detail about the differences of the various virtual environments for python

With that out of the way I would like to address your other concerns. When you use the django-admin.py script to start a project and you just supply the project name, It will create a containing folder with that name that holds the manage.py scripts and a subfolder within that directory with the same name that houses your actual project files. When you put a dot after the project name, the dot refers to the current directory, the one where you are running the command, and it will use that to store the manage script and then create a folder for your actual project. If that makes any sence. Both ways get the job done, they create a virtual environment each with their own python and their own modules, isolating anything you do in them from the systems python site-packages.

when you do source bin/activate you are referencing a script that sets up some environment variables on your behalf and changes your prompt to remind you that you are working inside a virtual env so any modules you might install for python are going to that environment.

the manage script is for your project so it has knowledge of your project settings. User scytale answers the question of django-admin vs manage better than I can https://stackoverflow.com/questions/3219...r#32199813

manage.py migrate will construct the database when first executed, its responsible for merging changes to the database, in the default case, changes to sqlite. Because Django works with a database it uses this in combination with manage.py makemigrations to manage the database changes when say you add modules or such.

Please correct me where I am wrong, these are my understandings. I am still new.

[Drone4four]

@mepyyeti: Perhaps the word you are looking for to replace "style" is simply "way"? There is more than one way to start a Django project. The author of one book might recommend using venv. In another book the author might recommend using virtualenv. In one of the StackOverflow links shared by @knackwurstbagel, there are half a dozen (maybe more?) other ways to create and use a virtual environment. No one way is the right away. It's up to you. As you develop as a programmer, you will develop your own preferences and style.