Unclear about folder structure with virtual environment

Using Django Getting Started
1

I’m still new to Django, lol (about a week into it). Using v4.0.1 (on Windows 10), which seems to be a little different from all the 3.x versions that tutorials all over the Web are focused on.
Without going into all the ways I came to the point of posting this question, I’ll just show you this structure first…

C:\www
    |-- myproject
    |    |-- Include
    |    |-- Lib
    |    |-- testsite/
    |    |    |-- testsite /
    |    |    |    |-- __init__.py
    |    |    |    |-- asgi.py
    |    |    |    |-- settings.py
    |    |    |    |-- urls.py
    |    |    |    |-- wsgi.py
    |    |    |-- manage.py
    |    |-- Scripts/
    |    |-- pyvenv.cfg

…and then ask: Does that look correct to you? I ask because I thought there was supposed to be an actual venv folder in there somewhere. In the command prompt I see this:

(myproject) C:\www>

Where I thought I might see something more like this (per other tutorials):

(venv) C:\www\myproject>

I have found zero tutorials for v4.0.1 outside of the official docs, but even those seem unclear in some areas, which is why I came here to ask. :slight_smile:

2

Hi! Welcome to the world of Django.

So probably the reason you won’t find any definitive answers on this topic is because there aren’t any.

There’s no one right-way to set up your environment, just different practices based on need.

Keep in mind:

  • Python virtual environments exist to allow you to keep separate groups of libraries for different “projects” or groups of projects. The virtual environment itself is not a part of your Django project, it is effectively a container (generic term, not in the “docker” sense) for the libraries that your Django project will use.

    • Some people will put their virtual environment within their projects because they have separate virtual environments for each Django system they build.

    • Some people put their virtual environments in other locations. In my case it’s because I typically end up building multiple projects based on the same virtual environment - I want to ensure everything remains consistent between projects.

  • In essence, your Django code runs “inside” the virtual environment, not the reverse. (The Python runtime environment runs Django, and then Django runs your code.)

(By the way, this is actually a fairly common question that gets asked. There have been a couple of discussions on this topic here. See Correct practice for importing third party modules as one.)

As a side note, the basics of deployment and project organization have not changed between Django v3 and v4. Without looking at those tutorials in detail, I’m willing to guess that there probably aren’t any material differences that would prevent you from learning.

1 Like
3

So let’s see if I’m understanding this correctly. First of all, my www folder is where I want to keep all my projects (same as I keep all my PHP sites in an htdocs folder). So if I have this:

(myproject) C:\www>

Is it correct to say that www is inside the virtual environment? Therefore every project I create is inside the same environment?

And if I have this:

(venv) C:\www\myproject>

Then a specific project is inside a virtual environment? Therefore, this:

(venv) C:\www\myproject>
(venv) C:\www\myproject2>
(venv) C:\www\myproject3>

indicates each project is inside their own environment?

I’m coming from the ‘old’ world of PHP, and still getting used to this whole concept. Thanks for the link and ‘heads up’ about the basics.

4

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. (E:\work\)
Within that directory, I have directories named git and ve. (E:\work\git and E:\work\ve)
Within git, I might have project_a and project_b - each of which being standard Django-organized projects.
Within ve, I might have directories env_1 and env_2. (E:\work\ve\env_1 and E:\work\ve\env_2) Each of those is a virtual environment.

To run either project_a or project_b, I would activate either env_1 or env_2.

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 project_a and project_b.

1 Like
5

Thank you so much for the work you put into your replies. At this point I feel like I’ve never done Web development before in my life, LOL (20+ year veteran of doing so).

I’m beginning to get a clearer picture of how things work. Stay tuned for more newbie questions from me… hahaha.

6

@KenWhitesell, just to check if I’m on the right track, is this more like what I should be seeing?

C:\projects\
 |-- project1\
 |    |-- project1\
 |    |    |-- __init__.py
 |    |    |-- asgi.py
 |    |    |-- settings.py
 |    |    |-- urls.py
 |    |    |-- wsgi.py
 |    |-- manage.py
 |-- project1env\
 |    |-- Include\
 |    |-- Lib\
 |    |-- Scripts\
 |    |-- pyvenv.cfg

Command prompt shows this:
(project1env) C:\project1>

I realize that that’s probably one possibility of many, but I want to be sure I’m starting with something correct/usable, before I move forward. Thanks!

7

Hate to bump this, but hopefully someone can answer my last question. :slight_smile:

8

Directly for the question you’re asking, yes, that will work.

Indirectly, I’d express the opinion that at this time, you’re expending too much energy worrying about this.

What I’ve tried to make clear in my previous replies is that there is no structural file-system relationship between your Django project code and the virtual environment in which it runs.

Key points:

  • Whatever works for you is good
  • You’re not “locked” into anything
    • This is something that’s really easy to change at any point in time
  • Choosing one option does not prevent you from also selecting a different option
    • And even changing between them intermittently
  • There are sometimes (good) reasons for choosing one structure over another
    • Those reasons generally are for “management” reasons, not technical reasons
9

Okay, thank you. Just not used to this way of working, and didn’t want to do something that needs to be reversed or altered when it’s too late.

Thank you for your help.

10

Actually you are - just perhaps not from this perspective.

For example, consider a typical program you might install - say LibreOffice. You can install it in any arbitrary location. It doesn’t matter what directory you install it in, you can use it to edit files in any location.

And, if it’s “clean” from a dll perspective (I don’t know if it is or isn’t), you can have multiple versions installed in different directories, and select from them arbitrarily.

For any given document, you can use it in any of your installed instances.

You can store those documents just about anywhere. You could create a documents directory within your LibreOffice installation directory and save them there. You can create an external documents directory for storage.

The key point here is that it just doesn’t matter what the directory relationship is between the location of the LibreOffice runtime and your documents.

The abnormal situation are those that mandate a structural relationship between a runtime environment and the code being executed by it.

1 Like