Refs #33650: Changes to the startproject template

[FlipperPA]

This PR 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. These two pain points came up the most frequently. Having to explain and distinguish between two directories with the same name is a pain point in the teaching process - "cd into my_project ... no, the other one!"

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.

I wanted to open this PR for discussion; if we decide this is a direction we would like to move in, we'll need to update the documentation and contact folks who maintain third-party tutorials (DjangoGirls, SimpleIsBetterThanComplex, etc).

Ticket: https://code.djangoproject.com/ticket/33650

[hazho]

amazing job @FlipperPA

[FlipperPA]

Over the course of this PR, the single test failure that is shown passed and failed intermittently. Any advice on whether this is something to do with my PR, or something systemic? This is the test:

pull-requests-bionic/database=spatialite,label=bionic-pr,python=python3.10 — Build #15758 ended

[hazho]

it is related to Spatialite DB backend, shows that is not compatible with Python 3.10, IMO, I don't think you need to do any modification

[felixxm]

it is related to Spatialite DB backend, shows that is not compatible with Python 3.10, IMO, I don't think you need to do any modification

It has nothing to do with compatibility. This test is flaky, see ticket-32831.

[FlipperPA]

Thanks for letting me know @felixxm - I missed that ticket. Good to know, because that's the behavior I observed.

[apollo13]

Personally I do not like config as a name and do not think that this is something that should be on the python path. What if we could just rename the outer dir to something else? Ie <project_name>_project or so?

[FlipperPA]

Thanks for the feedback, @apollo13. Unfortunately, that somewhat defeats the intent; when teaching newcomers, having a static path that will be exactly the same is the largest benefit from my experience. We seemed to reach that consensus on the thread on the Django developers list. For reference, here's that discussion: https://groups.google.com/g/django-developers/c/SwFAy8GbhmE

Have a great weekend!

[apollo13]

Hi Timothy,

Consensus seems a bit far stretched. From those who answered I see a bit of a preference for your approach but Adam's approach with a single namespace for project and apps has a few followers as well (me included).

While the docs do recommend it I am also not really a fan of the custom user app, especially since it does not address any of the shortcomings in the existing one (name vs first & last name for instance). I do get that changing the user model is not easy, but let's be blunt, 99% of the projects can get away with the existing one.

I understand that the default project model is suboptimal for teaching but let's not throw python best practices over board just for this (namespaces are a great idea). As a namespace I personally do not think 'config' is a great idea, next thing to happen is the app gets named 'requests' because it handles user requests and you are back to square one explaining why that was a bad idea and why you no longer can use the requests module. I'd love to find a middle ground that aknowledges that python packages and modules are a thing as well. At the minimum ensuring that the two directories are named differently would already be a massive win no (no more explaining which of the two you mean)?

I am not sure how to put this, but I think that a change like this which literally affects every user should probably have a DEP exploring alternative options and then in the worst case a voting of the technical board (I honestly do think that even without my technical Board hat on).

A great weekend to you as well!

On Fri, May 13, 2022, at 20:48, Timothy Allen wrote:

Thanks for the feedback, @apollo13 https://github.com/apollo13. Unfortunately, that somewhat defeats the intent; when teaching newcomers, having a static path that will be exactly the same is the largest benefit from my experience. We seemed to reach that consensus on the thread on the Django developers list. For reference, here's that discussion: https://groups.google.com/g/django-developers/c/SwFAy8GbhmE

Have a great weekend!

— Reply to this email directly, view it on GitHub https://github.com/django/django/pull/15609#issuecomment-1126349522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAT5C6AFYGP4HEWTNYC54DVJ2PWXANCNFSM5TUNIRKQ. You are receiving this because you were mentioned.Message ID: @.***>

[apollo13]

Oh and while we are on it we should absolutely talk about putting stuff into a src/ subfolder 🙏

On Fri, May 13, 2022, at 20:48, Timothy Allen wrote:

Thanks for the feedback, @apollo13 https://github.com/apollo13. Unfortunately, that somewhat defeats the intent; when teaching newcomers, having a static path that will be exactly the same is the largest benefit from my experience. We seemed to reach that consensus on the thread on the Django developers list. For reference, here's that discussion: https://groups.google.com/g/django-developers/c/SwFAy8GbhmE

Have a great weekend!

— Reply to this email directly, view it on GitHub https://github.com/django/django/pull/15609#issuecomment-1126349522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAT5C6AFYGP4HEWTNYC54DVJ2PWXANCNFSM5TUNIRKQ. You are receiving this because you were mentioned.Message ID: @.***>

[FlipperPA]

I have tried to approach this from the perspective of making things straightforward for the newcomer, under the assumption that once someone has gotten some experience with Django and Python, they will know enough to solve any issues that might arise. For the newcomer, simple is better than complex. Another tier of directory structure would seem to make navigating a startproject template more intimidating for a newcomer to avoid an edge case of possible namespace conflicts, IMHO.

I agree wholeheartedly that first_name / last_name is not ideal and doesn't jive with our diversity statement but opted for something more straightforward (and again, that can be changed in the future). Changing the default AbstractUser model would seem to be a separate (but worthy!) project.

The advice I was given when the ticket was created was to create a discussion on the developers' mailing list, so I went ahead and did that. If consensus is that a DEP is in order, that expands the scope of this significantly. It also feels like this is part of the reason we're stuck with the status quo, which I think we all agree is not ideal. Take care!

[thibaudcolas]

Based on those last three comments – could @django/steering-council weigh in on whether this requires an accepted DEP to proceed? This seems to be blocked based on whether one is needed or not (considering the effort involved in writing a DEP).

Relevant discussions for context, from most to least recent:

• Mailing list: Improvements to the startproject template
• Forum: Django New Project Structure/Name
• #33650 Update startproject template with config directory
• #27909 Use AUTH_USER_MODEL in startproject template

Edit – and from DEP 10 Terminology, for future reference,

• "Minor Change" means fixing a bug in, or adding a new feature to, Django of a scope small enough not to require the use of the DEP process.
• "Major Change" means any change to Django's codebase of scope significant enough to require the use of the DEP process.

[FlipperPA]

If we get a consensus behind moving this forward, it could be a worthwhile project for DjangoCon US sprints in Durham two weeks from today. I've tutored over 100 people through the process of starting their first Django project, and the default startproject continues to be a large source of confusion during moments when we should be focused on making the experience as frictionless as possible.

[andrewgodwin]

DEP 10 is not entirely clear on this, but the way I read it, if the Mergers don't think it's small enough and has entire consensus then it warrants a DEP.

My read of the existing discussions does not show a strong consensus, so I'd say this is probably something that just edges over the line into needing a DEP.

[thibaudcolas]

Just noting I won’t pursue writing a DEP about this at this time (not enough mental energy nor technical knowledge on this area). If anyone else is interested, please go for it!