It is possible to do in current version of Django with two lines of code:mkdir
my_projectdjango-admin startproject config my_projectI have been working for
many companies that use Django and I have seen that each ot them has their own
structure of project. And usually project is created once per couple of months,
so I don't see advantages of changing project structure.Regards,AlbertTemat:
Re: Improvements to the startproject template
As there are different preferences and some see the change as
worse than the default and there is already a way to change the
template for startproject, wouldn't it be easier to provide
different templates and list them in the documentation, so that
they can be used with the --template argument? With a short
section about each template and the pros and the cons, and for
what kind of project one is better suited.
Maybe the three top templates could be shipped directly with
django, so that users could choose one with --template=simple,
--template=nested or --template=config or something in that
direction.On Thursday, April 21, 2022 at 11:16:23 AM UTC+2
ator...@redhat.com wrote:I personally dislike Adam's suggestion and feel like
it makes it worse than the current default, but to each their own.I do prefer
the proposed solution of the config directory, I am working on two django
projects in parallel and one follows the proposed config scheme and the other
doesn't (uses the default) and I find the proposed config scheme more natural
to use and navigate, so that's a +1 from me tooOn Thursday, April 21, 2022 at
5:10:06 AM UTC+2 pem...@gmail.com wrote:For what it's worth, this is the
(general) layout I've used for the past 8+ years of my professional Django
development.ArthurOn Wed, 20 Apr 2022 at 15:22, Olivier Dalang
<olivier...@gmail.com> wrote:+1 for Adam's suggestion, I use it as well
and like it very much.> root folder - manage.py -
... > myproject - __init__.py
- settings.py - urls.py
- ... > myapp
- __init__.py
- models.py - ...Pros:-
everything is well namespaced under myproject (`myproject.settings`, quite
straightforward)- makes it clear that `settings.py`, `urls.py`, etc. concern
the project as a whole, and not just an app.- also nice in
settings.INSTALLED_APPS (`myproject.myapp` makes it clear that myapp is part of
this project)- it leaves the root level for stuff like .gitignore, db.sqlite,
etc, so the actual source stays clean from such files.- having a parent package
allows (does not require) relative imports across modules of the same
project, which more clearly conveys that such apps are tightly coupled- with
manage.py still in the root folder, you don't need to cd into any folder to
start workingI use it all the time.Cheers,OlivierLe mer. 20 avr. 2022
à 18:50, Tom Carrick <t...@carrick.eu> a écrit :I prefer Adam's
suggestion in the forum post as it lets you namespace everything under your
project name nicely and avoids package name collisions, although it doesn't
solve the problem of having two directories with the same name by default.That
said, either would be an improvement on what we have so I'm in favour of either
approach over doing nothing.Cheers,TomOn Wed, 20 Apr 2022 at 16:49, John M
<john-...@martinhome.org.uk> wrote:
I do exactly this for every new Django project, so it's +1 from
me as well.
John
On 20/04/2022 12:01,
da...@springbourne-tech.com wrote:
+1 for me - this would be really useful.
On Monday, April 18, 2022 at
9:02:02 PM UTC+1 pyt...@ian.feete.org wrote:
Hi Tim,
This feels like a good idea to me.
Regards,
Ian
On Mon, 18 Apr 2022 at
18:17, Tim Allen <fli...@peregrinesalon.com>
wrote:
Greetings, friends!
I've issued a PR that makes two changes to the
`startproject` template:
instead of putting configuration files such
as `settings.py`, `wsgi.py`, and the
root `urls.py` in `my_project/my_project`,
they are
created in `my_project/config`
start the project with a custom User model
app, `users`
Over the years, I've taught or tutored
over 100 Djangonauts starting their first project.
Having to distinguish between two directories with the
same name is a constant pain point in the teaching
process - "cd into my_project ... no, the other one!"
The `config` option seemed to be the consensus
from this thread in the forum: Django New Project
Structure/Name - Using Django - Django Forum
(djangoproject.com)
Ticket: https://github.com/django/django/pull/15609
It is sometimes better to show rather than tell, so
following our own documentation and including a custom
User model with the initial project template reinforces
the best practice that we explicitly point out in the
documentation.
Ticket:
#27909 (Use AUTH_USER_MODEL
in startproject template) – Django
(djangoproject.com)
Avoids ever having this come up
again: https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
Here's a link to the
PR: https://github.com/django/django/pull/15609
My apologies for not starting with a
discussion first. I'm an infrequent contributor to the
Django codebase!
Regards,
Tim
--
You received this message because you are subscribed to
the Google Groups "Django developers (Contributions to
Django itself)" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.com.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a184bfc1-e3fb-4bd7-8378-292194e52595n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ffb8a027-d5c7-53b4-1ea7-c9f687b8c80d%40martinhome.org.uk.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaFmJYbV2mgek4WivuBepJgt46d6cgcD-Vtp2MBspcFnA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAExk7p1tnn5xx9bQEKfbZMjdajJ2TSH39tVWujSgk3vtOnCTYA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7acdab41-6246-49e3-9b21-fcce4a7690f5n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/itdulrnhrftdumjfnjhn%40eumz.
