Closed Leeaandrob closed 7 years ago
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β¦Β
@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:
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
The core rationale of what I do is:
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.
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.
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.
Anytime, dear friend! :)
Closing this Issue since:
So, in many projects that I have seen the utilized structure is:
Maybe this could to be a issue to fix it?