Follow-up to #28307: Possible app_template improvements

[mark.ca...@gmail.com]

Hello everyone,
I'm a Django user for some years now, and I find myself tweaking the app structure after `./manage.py startapp foo`.

I try to modularize the code and keep things separated. For example I don't like form classes in `views.py`, or very long `tests.py` files (and after also the Django code is organized like this).

Sometimes, especially when developing an app/project in more than one or two people, some bad habits can kick in, like:
* I'll just declare this little form class in `views.py`, because a separate file only for this is too much
* I need another form class, but there is also the previous form class here in `views.py`, no reason to create a `forms.py` file and have some form classes here and some there
* Now `views.py` is a big file and the effort to refactor can be too overwhelming now, also because we have to ship the code (for murphy-law-esque reasons you'll think that you HAVE to refactor in the worst moment. Hence you WON'T refactor.)

And the entropy tends to rise and rise.

The same can go for a single `tests.py` file.

So I forked django and did a slightly different (cleaner, I think) app_template, and filed a ticket in the bug tracker.

The ticket: https://code.djangoproject.com/ticket/28307
The branch on my forked project: https://github.com/mcagl/django/tree/mcagl/better-startapp-template

It was then that I was directed to raise the question here in the developer's mailing list, so I'm trying to recap the proposals here (and I hope to have done everything correctly):

* New files: `forms.py`, `middleware.py`, `mixins.py`, `urls.py` to encourage the developer (that can be a newbie) to start with a separation of things that will pay in the long run (and to reinforce the architecture of Django itself in the developer's mind)
* Refactoring `tests.py` in a `tests` module, also to encourage modularity.

I was made aware of the `startapp` option to make it use a custom template, but I think that a cleaner template used by default by Django can be a benefit to instill what I think are good habits in the Django developer community.

What do you think about this proposal?

Kind regards,
Mark

[Aymeric Augustin]

-- 

Aymeric.

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0da65cd4-0496-4ec5-99b5-3d94e887dcb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

Hello,

The more files get generated to startapp, the more empty useless files accrue in many projets, because devs don't take the time to delete those they don't use.

Encouraging people to improve the structure of their Django code is worthwhile but I don't believe the startapp template is the right medium for that.

Also the best structure will depend a lot on the context. There are many valid opinions on what the proper default structure is, depending on each person's experience.

For this reason, I'm skeptical of attempts to extend the startapp template. I'm more interested in trimming it down.

IIRC we had the discussion quite recently. Perhaps you can find that discussion in the archives.

Best regards,

-- 

Aymeric.

On 14 Jun 2017, at 21:30, mark.ca...@gmail.com wrote:

[Curtis Maloney]

On 15/06/17 16:14, Aymeric Augustin wrote:
> Hello,
>
> The more files get generated to startapp, the more empty useless files
> accrue in many projets, because devs don't take the time to delete those
> they don't use.

Beat me to the punch... I agree the default template should be as light
as possible.

> Encouraging people to improve the structure of their Django code is
> worthwhile but I don't believe the startapp template is the right medium
> for that.

There's no reason we can't provide an "advanced" template in core, surely?

IMHO project/app templates are one of the least utilised features of
Django, sadly.

It deserves more marketing :)

--
Curtis

[Adam Johnson]

I agree with Aymeric and Curtis too. You could distribute your startapp template as a third party package, even overriding the built startapp manage command to use your template by default.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9167ee89-f406-196b-28ec-5ba63ea1b049%40tinbrain.net.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Melvyn Sopacua]

On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:

 

> The more files get generated to startapp, the more empty useless files

> accrue in many projets, because devs don't take the time to delete

> those they don't use.

 

...

 

> For this reason, I'm skeptical of attempts to extend the startapp

> template. I'm more interested in trimming it down.

 

I see the point for the number of useless files. But in every release, settings.py has been trimmed more and more to the point that it's next to useless. I'm wondering about the upside of that. Cause I'm seeing plenty of downsides for both new and veteran users.

 

Not to mention the choice of what to remove. To keep STATIC_URL (which I rarely change) but remove STATIC_ROOT (which is different per project and sometimes even per install) is beyond me.

 

--

Melvyn Sopacua

[Curtis Maloney]

On 26/06/17 20:21, Melvyn Sopacua wrote:
> On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:
>
> I see the point for the number of useless files. But in every release,
> settings.py has been trimmed more and more to the point that it's next
> to useless. I'm wondering about the upside of that. Cause I'm seeing
> plenty of downsides for both new and veteran users.

Can't say I agree it's useless... I find I need very little to modify
the start project template to get under way... especially now that admin
is in by default.

> Not to mention the choice of what to remove. To keep STATIC_URL (which I
> rarely change) but remove STATIC_ROOT (which is different per project
> and sometimes even per install) is beyond me.

Because STATIC_URL is useful always, whereas STATIC_ROOT typically only
makes sense when you deploy...


--
Curtis

[Melvyn Sopacua]

On Monday 26 June 2017 20:25:58 Curtis Maloney wrote:

> On 26/06/17 20:21, Melvyn Sopacua wrote:

> > On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:

> >

> > I see the point for the number of useless files. But in every

> > release, settings.py has been trimmed more and more to the point

> > that it's next to useless. I'm wondering about the upside of that.

> > Cause I'm seeing plenty of downsides for both new and veteran

> > users.

>

> Can't say I agree it's useless... I find I need very little to modify

> the start project template to get under way... especially now that

> admin is in by default.

 

Right. Sane defaults are a good thing. Doesn't address why trimming it down is a good thing.

 

> > Not to mention the choice of what to remove. To keep STATIC_URL

> > (which I rarely change) but remove STATIC_ROOT (which is different

> > per project and sometimes even per install) is beyond me.

>

> Because STATIC_URL is useful always, whereas STATIC_ROOT typically

> only makes sense when you deploy...

 

But in doing so the educational part is removed. That there's a STATIC_URL and a STATIC_ROOT that need to be mapped by the webserver. The drawback of what is there now, is that it works and you have no clue why it doesn't once deployed, as you have had no reason to click the link.

 

And since STATICFILES is suddenly one word, I've spent several minutes trying to find out why my static dir isn't picked up. Or why I can't connect to the database, because it's 'USER' not 'USERNAME'.

 

Boiler plate is supposed to save you time in typing and looking up things and it's in shear contrast with this trimming fashion.

--

Melvyn Sopacua

[Aymeric Augustin]

Hello Melvyn,

> On 26 Jun 2017, at 12:21, Melvyn Sopacua <m.r.s...@gmail.com> wrote:
>
> keep STATIC_URL (which I rarely change) but remove STATIC_ROOT (which is different per project and sometimes even per install) is beyond me.

Back when Apache + mod_wsgi was the standard deployment stack, collecting staticfiles inside the project tree was a bad security practice. For that reason it couldn't be the default. A safer default value such as `/var/www/{project_name}/static` would require additional setup and wouldn't work well as a default.

(It's a bad security practice because developers just trying to make it work tend to `chmod -R www-data:www-data /home/{project_name}`, making their whole source tree world-readable, because they're having trouble getting static files to work.)

Nowadays it's more common to serve static files from a third-party system such as CloudFront + S3 which doesn't require STATIC_ROOT or with a middleware like whitenoise which doesn't suffer from this concern. Only in the latter case is `STATIC_ROOT = os.path.join(ROOT_DIR, 'static')` a valid default.

Given this range of options, I still find it best for users to think about what they're doing, read the docs, hopefully review security considerations, define the settings they need and understand their deployment. I also believe that unused settings can be confusing and make it more difficult to diagnose deployment problems.

I'm sure there's a more extensive project template somewhere that will suit your needs better.

Best regards,

--
Aymeric.

[Melvyn Sopacua]

Hi and thanks Aemeric,

On Tue, Jun 27, 2017 at 7:55 AM, Aymeric Augustin
<aymeric....@polytechnique.org> wrote:
> Hello Melvyn,
>
>> On 26 Jun 2017, at 12:21, Melvyn Sopacua <m.r.s...@gmail.com> wrote:
>>
>> keep STATIC_URL (which I rarely change) but remove STATIC_ROOT (which is different per project and sometimes even per install) is beyond me.
>

> Nowadays it's more common to serve static files from a third-party system such as CloudFront + S3 which doesn't require STATIC_ROOT or with a middleware like whitenoise which doesn't suffer from this concern. Only in the latter case is `STATIC_ROOT = os.path.join(ROOT_DIR, 'static')` a valid default.

Thanks, that clarifies it this specific setting (all though not all
prefer to use services that interfere with SSL trust). But...

> Given this range of options, I still find it best for users to think about what they're doing, read the docs, hopefully review security considerations, define the settings they need and understand their deployment. I also believe that unused settings can be confusing and make it more difficult to diagnose deployment problems.

... this is where we respectively disagree. While it's possible that
things may get clouded, you *can* in fact see what is set.

This:
# DEBUG = False

trumps this:
<empty line>

Also note that if you want things concise, it's much faster to "select
and delete" then "lookup name of setting, copy, paste and alter".

And finally, a diff will show what changed, as opposed to what was
added (which may or may not be a change of the default).

> I'm sure there's a more extensive project template somewhere that will suit your needs better.

Yep, probably should do that and allocate time maintaining it.
--
Melvyn Sopacua