Can anyone explain how to create a virtual environment for a django app and use that same virtual environment folder as the folder for that django app? I have a master folder called django_projects where all my django apps are contained, separate folders for each django app. I don’t want multiple hierarchical folders with the same similar names to avoid confusion dont mind reconfiguring what ever paths needed.
For example after creating a django app folder say {app1}, I run mkdir app1 && cd “$_” then I run virtualenv . --prompt app1_venv. After running source bin/activate, I want django-admin startproject name app1 to have the same name and folder. Or is this a bad workflow since venv folder contains all binaries? Therefore no choice but to have the django app folder under a virtual env hierarchy? Thank you for your insight.
There have been a couple conversations on this topic here in the past.
See:
Read it all but still not 100% clear, but definitely getting closer. Thank your for the links. Couple more questions
- I understand your point on too much emphasis on locations/ folder hierarchy, which might seem easier to understand and navigate for some one with familiarity in Django within a certain workflow :
a) using a naming convention for virtual environments and the associated project folder regardless of it being a django project, or one ve for multiple projects, I mean how would u keep track other that looking at the code/path variables? I see u said in post ve-env1, env1 etc…, secondly aside from simplistic one to one relationship, how do we keep track on a one to many relationship? ve:project(s)
b) If we get past that and say we choose ve in different locations than the project (django in this case), assuming each instantiation of ve and django-admin startproject, tracks and records where each folder for each instantiation is stored, is there any other variables we would have set regarding paths, is it seamless after?
So what Im getting at is:
I have a ve folder with some sort of naming convention to keep track of referring projects:
\all_venvs
virtualenv ve_with_some_naming_convention_x (folder) --prompt ve_with_some_naming_convention_x (command_prompt)
folders:
ve_with_some_naming_convention_x/
bin/
include/
lib/
penv.cfg
ve_with_some_naming_convention_y/
"
ve_with_some_naming_convention_z/
"
→ according to django docs:
django-admin startproject mysite1, django-admin startproject mysite2 etc…
\all_django_projects:
\mysite1
manage.py
\mysite1
__init__.py
settings.py
urls.py
asgi.py
wsgi.py
\mysite2
manage.py
\mysite2
__init__.py
settings.py
urls.py
asgi.py
wsgi.py
\mysite3
manage.py
mysite3/
__init__.py
settings.py
urls.py
asgi.py
wsgi.py
Is it up to the developer to keep track or we have to refer to set paths to figure which is which? Also mysite_x is mentioned with double hierarchy, my original question is how to avoid this, for me I prefer to avoid using the same recursive folder names. Mysite_X is developper created and the sub folder mysite_x is django created. How ever in django documentation says the parent folder is as an example /home/mycode .
Regarding the virtual environments - keep in mind that the virtual environment is the Python executable and a set of third party libraries. Your Django project runs within the environment defined by those libraries.
What that means is that it’s quite possible to create a project that runs in multiple environments, provided the combinations of libraries being used are all compatible. For example, you could create a Django project that runs in all of Django 3.2, 4.0, 4.1, and 4.2.
If you’re in a situation where that is necessary, then you would set up different environments for those four versions of Django, being able to run your project in each.
Other than defining the basic requirements, your Django project doesn’t need to know or care which environment it’s running in. There’s nothing that you should be defining within your project that in any way directly references that environment.
And yes, it’s up to you to know which environment(s) need to be activated to run a project.
Regarding the directory structure, you didn’t format your text to maintain the spacing, so it’s not entirely clear what you intended, but what I think you have is (with some additions of my own):
all_projects\
mysite1\
mysite1\
otherapp1\
otherapp2\
mysite2\
mysite2\
otherapp3\
otherapp4\
mysite3\
mysite3\
otherapp5\
otherapp6\
Yes, this is the basic default layout for multiple projects within a single directory. I’m not following what you’re question is trying to determine beyond this - what are you trying to figure out?
Note that all_projects could be anything. It could be your home directory such that instead of /home/ken/all_projects/mysite1/, etc, it’s /home/ken/mysite1/, etc. That’s entirely up to you to choose and manage.
Finally, I don’t deny that some people are confused by the “doubled directory” names. That is a default selected by the Django startproject command, and is a handy convenience.
You can freely change the name of the outer directory if you wish. It’s just a directory for the entire project.
The inner directory is a Python module from Django’s perspective. That means that changing the name of the inner directory would also involve changing all the references to it in your manage.py, wsgi.py, settings.py, and asgi.py (by defaults - there are other files that could end up needing to be changed.)
Regarding the virtual environments - keep in mind that the virtual environment is the Python executable and a set of third party libraries. Your Django project runs within the environment defined by those libraries.
What that means is that it’s quite possible to create a project that runs in multiple environments, provided the combinations of libraries being used are all compatible. For example, you could create a Django project that runs in all of Django 3.2, 4.0, 4.1, and 4.2.
If you’re in a situation where that is necessary, then you would set up different environments for those four versions of Django, being able to run your project in each.
So one django project with 4 ve per django version?
Other than defining the basic requirements, your Django project doesn’t need to know or care which environment it’s running in. There’s nothing that you should be defining within your project that in any way directly references that environment.
And yes, it’s up to you to know which environment(s) need to be activated to run a project.
Can u give an example of the naming conventions your would employ to keep track?
Regarding the directory structure, you didn’t format your text to maintain the spacing, so it’s not entirely clear what you intended, but what I think you have is (with some additions of my own):
all_projects\
mysite1\
mysite1\
otherapp1\
otherapp2\
mysite2\
mysite2\
otherapp3\
otherapp4\
mysite3\
mysite3\
otherapp5\
otherapp6\
Whats significance of otherapp?
Yes, this is the basic default layout for multiple projects within a single directory. I’m not following what you’re question is trying to determine beyond this - what are you trying to figure out?
1) avoid confusion to keep track of which goes with which
2) avoid doubled folders
chose to use django in ve folder to make 1) straight forward
I just did:
virtualenv re_app --prompt "$_"
cd re_app
source bin/activate
pip install black (had to for some reason error said was missing)
pip install django=4.1
django-admin startproject re_app .. (.. for ve directory)
Note that all_projects could be anything. It could be your home directory such that instead of /home/ken/all_projects/mysite1/, etc, it’s /home/ken/mysite1/, etc. That’s entirely up to you to choose and manage.
Finally, I don’t deny that some people are confused by the “doubled directory” names. That is a default selected by the Django startproject command, and is a handy convenience.
Whats the convenience?
You can freely change the name of the outer directory if you wish. It’s just a directory for the entire project.
The inner directory is a Python module from Django’s perspective. That means that changing the name of the inner directory would also involve changing all the references to it in your manage.py, wsgi.py, settings.py, and asgi.py (by defaults - there are other files that could end up needing to be changed.)
I wouldn’t word it that way. It’s 4 different VEs, each can run the same Django project. (or different projects)
I don’t. That’s not something I worry about. My VEs are more closely associated with a deployment environment than a project. And since I’m typically working on something specific for a particular environment, I know which VE I need to use.
They’re just other Django apps within your project. (And I’m using the term “app” here in its very specific Django meaning. See Applications | Django documentation | Django)
Having additional apps in your project is not a requirement - In fact, I’m a member of the “One app until it hurts” club. Other people have other opinions on this point.
If necessary, document it in a README file. Don’t rely upon naming conventions.
The folders aren’t “doubled”. The folder names are reused. Those two directories - while named the same - perform two different functions.
That may or may not work out well for you. I don’t see that as (fundamentally) any different from those who include their VE within their Django project. Whether or not that works depends upon how you’re going to deploy this.
And that, I think, is a key point that might be overlooked here. I’m getting the impression that you’re trying to “optimize” your development environment, without figuring out what’s going to work for you in your production environment.
If you pick a directory layout that works for development but doesn’t work for your production systems, then you’ve wasted a lot of effort setting it up.
It’s a convenience for the Django startproject command and the person using it. It’s one command with one parameter that sets up the outer “project” directory and the inner “module” directory. There have been other discussions here (e.g. "Project" Naming Conventions) that talk about the naming of that inner directory. We’ve just never found it bothersome enough to worry about it.