Applying good patterns to project layout

[Leeaandrob]

So, in many projects that I have seen the utilized structure is:

Maybe this could to be a issue to fix it?

[cuducos]

TBH I don't remember why I got used to do it the way it's done in this project. But actually I remember @henriquebastos taught me this way. Unfortunately I right now I can't remember the rational for that.

What I'm about to say is my opinion, totally biased by this architecture I'm been using for a couple of months.

In spite of being a Django standard (and supported by books as Two Scoops of Django) I tend to find this architecture you're suggesting confusing: my_app and mysite (following your example) are modules placed at the same location within the project tree, but they are not the same thing (my_app is actually a Django app while mysite is… well… Django basics to run the site).

Again: totally biased — cognition is based on tradition, and my tradition is to do the other way around.

That said, unless anyone give me a better reason not to change, I agree that this is an issue that could be fixed: following standards is a way to be more welcoming for contributors — in other words, I still can see a good side in following standards I disagree with… 

[luzfcb]

@cuducos probably in the next release of Two Scoops of Django book, the suggested project layout will be changed to the layout we use now: https://github.com/pydanny/cookiecutter-django/tree/master/%7B%7Bcookiecutter.project_slug%7D%7D

I do not like the default django layout, or the layout proposed by Henrique Bastos, I prefer the cookiecutter-django project layout, because at least for me, it's better to separate the things.

for this layout work, you only have to make three small changes on:

• manage.py
• wsgi.py
• common.py

the cookiecute-django layout looks like this

.
├── config # contains all django project related configurations
│   ├── __init__.py
│   ├── settings # settings.py has been separated into four files: local.py, production.py, test.py all inherit from common.py
│   │   ├── common.py
│   │   ├── __init__.py
│   │   ├── local.py
│   │   ├── production.py
│   │   └── test.py
│   ├── urls.py
│   └── wsgi.py
├── project_name # contains all project apps and templates
│   ├── contrib
│   │   ├── __init__.py
│   │   └── sites # this override migrations of django.contrib.sites app
│   │       ├── __init__.py
│   │       └── migrations
│   │           ├── 0001_initial.py
│   │           ├── 0002_set_site_domain_and_name.py
│   │           └── __init__.py
│   ├── __init__.py
│   ├── static # all apps static files
│   │   ├── css/
│   │   ├── fonts/
│   │   ├── images/
│   │   ├── js/
│   │   └── sass/
│   ├── templates # all apps template files
│   │   ├── 404.html
│   │   ├── 500.html
│   │   ├── account/
│   │   ├── base.html
│   │   ├── bootstrap4
│   │   ├── pages/
│   │   └── users/
│   └── users
│       ├── adapters.py
│       ├── admin.py
│       ├── apps.py
│       ├── __init__.py
│       ├── migrations/
│       ├── models.py
│       ├── tests
│       ├── urls.py
│       └── views.py
├── requirements # contains all python dependencies 
│   ├── base.txt
│   ├── local.txt
│   ├── production.txt
│   └── test.txt
├── requirements.txt
├──utility # contains all non-python dependencies and helper scripts
│  ├── install_os_dependencies.sh
│  ├── install_python_dependencies.sh
│  ├── requirements-jessie.apt
│  ├── requirements-trusty.apt
│  └── requirements-xenial.apt
├── compose # contains docker and docker compose files
│   ├── django/
│   ├── nginx/
│   └── postgres/
├── docker-compose.yml
├── CONTRIBUTORS.txt
├── docs
│   ├── conf.py
│   ├── deploy.rst
│   ├── docker_ec2.rst
│   ├── index.rst
│   ├── __init__.py
│   ├── install.rst
│   ├── make.bat
│   └── Makefile
├── env.example
├── LICENSE
├── manage.py
├── Procfile
├── pytest.ini
├── README.rst
├── runtime.txt

[henriquebastos]

The core rationale of what I do is:

1. The repository directory is the root of all things and contains many things: the code, docs, utilities, contrib, etc.
2. The django project directory should be one single Python package with all it's subpackages, submodules, and assets. It should be on the root repository directory.
3. I follow most of the unix project layout for the surroundings: doc, man, contrib, etc. But instead of the src directory I use the project name.
4. There should be as little directories as necessary, avoiding boilerplates to be used.
5. I always start with a core app at the heart of the project to avoid spanning too many django apps upfront.
6. Having many requirements can be a problem. I have only one. 2 at most if my test environment is too complex. My development environment should be equivalent to production to avoid deployment friction.

I use TDD, so refactoring is an assumed part of the evolution. So I trust that the inner layout will evolve as needed.

I also like both having static and templates dirs at the project root directory or using AppDirectoryLoaders. Many of my apps get factored out of the project as libraries, so that influences me on how I do it.

I hope this explanation helps somehow.

[henriquebastos]

Also I just noted the cookie cutter layout separates config from project code.

For me, personally, this is a critical no go.

There should be only 1 settings.py supporting many instances.

Django mixes project settings with instance settings. However with python-decouple one can easily extract instance settings to environment variables.

The main goal is to keep one concise tested codebase that can be seamlessly loaded into many instance: dev, local, stage, production, demo, playground, whatever.

[cuducos]

Many many thanks, @henriquebastos!

In fact your explanation made it clear for me: we have a lot of good reasons to argue for this architecture.

Personally this is my favorite — and now I understand why.

[henriquebastos]

Anytime, dear friend! :)

[cuducos]

Closing this Issue since:

• good is such a subjective measure and
• we have good reasons to use the architecture we're using but
• mainly because this Issue was opened in due to a PVT conversation in which we considered using Capistrano to automate the deploy — this hasn't happened yet and now we're moving towards Docker