Add draft for extended project template

[knyghty]

This is a draft draft until I get around to writing the reference implementation. It's mostly copying files so shouldn't take too long, just need the motivation :)

Happy to have early eyeballs on it though.

[czue]

Is this the appropriate place to have open-ended discussion about this topic? Or should that be reserved for the forum?

Big picture here's my two cents:

1. I love the idea of this initiative, though I think there will be widespread disagreement about what exactly should go into a new template.
2. I think this is the most important part of the DEP, "it will set a precedent for adding new templates into Django" and would advocate for a strong focus in making it possible to more easily use different templates. So much so that I wonder whether "single-command startproject templates with 2-3 official reference implementations" might be a more suitable DEP (or at least easier to get consensus on). Yes, I know you can already pass a folder or URL to startproject / startapp and I still think we can do better¸e.g. by having a list of options for people to compare in the docs, or potentially by making it easier for template authors to make them more discoverable and configurable.

[carltongibson]

Hiya. Fly-by comment. Thinking actively on this, rather than not responding. 😅

I think here is a fine place to discuss, at least to get to good draft status.

The motivation section is key. (… 🤔 TBC)

The current project isn't bad — it's just too many files for a project just kicking off. I think it's as we reach that level of complexity and greater that opinions really start to ramify, so keeping the existing template, and using that as the outer limit of what Django itself will provide is perhaps helpful. That leaves space for a couple of simpler templates.

Then, pondering the startproject command. (… 🤔 TBC)

[knyghty]

One thing I thought of, though I think it's a bad idea, is related to Cory's idea (maybe exactly the same), is that to get whatever new thing to be the default without making it the default could be to have a new command, e.g. django-admin new that would ask some questions and choose a template based on that.

I'm not sure if it's worth putting in the DEP, because it would either require a package to handle the "UI", a good amount of code I'm unsure how to write, or a very basic interface (such as when choosing options when creating migrations). Leaning towards the last of those three things. And of course having --noinput to use whatever we choose as the new default. Then startproject can stay around as is, or be eventually removed in favour of new.

It would change the scope of the DEP though, maybe not in a bad way, but still, wasn't what anyone had in mind I think.

Just random ideas :)

[knyghty]

To expand slightly, the question could be as simple as:

What type of project do you want to create?

1. A standard project (default)
2. A fancy pants project with frontend things added for you (???)
3. A single file quickstart project for prototyping
4. A third party app
5. A classic project

Where a classic project would be the current template.

More things to maintain, though. And going this road leads to questions: should we add a pyproject.toml, how much configuration should we have, how opinionated should we be, etc. I would err on the side of doing as little as possible, though pyproject.toml feels standard enough to add for the user by now. But I also don't want to get lost in the rabbit hole of .editorconfig, .gitignore and other things that I always use, but are probably too opinionated (some people are probably still using mercurial, for example).

[knyghty]

The motivation section is key. (… 🤔 TBC)

I agree here and I think my motivation section is too light. It doesn't feel very compelling to me. Which is strange because a lot of people have strong opinions on why we need to change it, including myself. Open to ideas, but I also plan to properly sit with this and think it over.

[carltongibson]

… properly sit…

Yes, me too. That’s why just the initial comment. 🤹

[czue]

Agree the motivation is key. If the motivation is solely as-written (improving the tutorial experience) then my comment/position doesn't really apply. My motivation is improving the speed and choices for people who want build things with Django.

wasn't what anyone had in mind I think.

Who is the "anyone" referenced here? When i read through the linked forum posts I don't really see any obvious consensus, so just wondering if there's a backchannel motivation for this specific change (or a discussion I missed elsewhere). I don't want to derail an initiative to make progress because it's not enough progress if I'm bringing in requirements that feel out-of-scope.

If we are trying to broaden the scope I would have more to say (and think about!) but will hold off for the time being...

[knyghty]

Who is the "anyone" referenced here

Anyone. Nothing backchannel. But I didn't see this mentioned anywhere. So we have a consensus (I think) to do something, but the approaches vary, and the one I just mentioned hasn't been talked about that I know of.

But this broadening of the scope would allow us to do more (possibly: enough) without breaking backwards compatibility. But I do need to go think about it.

[Kagee]

I really like this suggestion. To not do to much in one, it sounds sensible to only add the required templates and files, and not cram in other nice-to-have files. A project.toml may be just simple enough though.

Since it will also potentially draw in many new dependencies, maybe the fancy-pants option should be dropped, and replaced with a (as last option) "Paste a link to a project template" as startproject supports now, but is somewhat hidden?

(Since i just popped up out of nowhere - i picked up this PR from the Django Discord, also relevant: https://github.com/Kagee/django-single-folder-project-template )

[knyghty]

Since there was a lot of positive feedback on the new command I have included this in the proposal.

I've also fleshed out the motivation section for different user types.

I will try to write up the reference implementation during this weekend.

[Kagee]

I suggest making it clearer in the text/wording that the new default project will use the "merged project/core app layout", not just a classic project and a classic preinstalled core app. While it is "explained" using the tree view, i feel it is not clear from just reading the text.

[knyghty]

@Kagee makes sense, I updated the wording.

[Kagee]

Have you considered referencing the different templates using slug-names, so they could be chosen when batch-processing, possibly based on the folder-names for the templates to be used? merged-project-app, single-file, third-party-app, classic-project-app?

[knyghty]

I added a link to a reference implementation. I didn't test that the project templates actually work, but I think it gets the idea across.

One thing I noticed, startapp has a context variable camel_case_app_name used for the AppConfig class name. We'd likely need to add something like camel_case_proejct_name to startproject as well, to get this working there.

[Kagee]

Afaik camel_case_project_name already works? Ref myself https://github.com/Kagee/django-single-folder-project-template/blob/main/project_name/apps.py-tpl#L4

[knyghty]

Indeed. Not very well documented :)

I've changed that now in the implementation. Thanks for the heads up.

[czue]

will there be any functionality for 3rd party templates to use django-admin new? that is something I would hope we could preserve from startproject. i also think it would be nice if it were slightly more flexible than the current startproject customization.

I think to foster an ecosystem of useful 3rd-party templates the ideal syntax should be something like:

django-admin new <project-name> --template-url https://github.com/owner/repo

[knyghty]

@czue I'm not planning this as a replacement for startproject, which already does this. You can still use a tempalte URL by pasting it instead of a number, this is mentioned in the prompt of the reference implementation when you use it: https://github.com/knyghty/django-new/blob/main/django_new/management/commands/new.py#L26

[knyghty]

@carltongibson, since I have you down as shepherd - I've advertised this everywhere I can think of and only gotten positive responses and mostly crickets here.

What do you think? Should we merge? Does it need more detail? Do I need to drum up support? Wait to see how the SC organises itself? Something else?

[carltongibson]

@knyghty I think we should let the SC election unfold, and circle back to this in January. (We can't advance it without a functioning SC in any case.)