Re: [Django] #35674: Provide a check for settings removed (post deprecation)

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Adam Johnson):

I did a quick grep for `setting.*removed` in `docs/releases` and found the
below. It’s likely incomplete but a good starting place. I think we
shouldn’t have a cut off and should feature all these settings in the
check. Projects can be very long-lived...

5.1

* `DEFAULT_FILE_STORAGE`
* `STATICFILES_STORAGE`

5.0

* `DATABASES->name->TEST->SERIALIZE`
* `USE_L10N`
* `USE_DEPRECATED_PYTZ`
* `CSRF_COOKIE_MASKED`

4.1

* `CSRF_COOKIE_MASKED`

4.0

* `SECURE_BROWSER_XSS_FILTER`
* `PASSWORD_RESET_TIMEOUT_DAYS`
* `DEFAULT_HASHING_ALGORITHM`

3.1

* `FILE_CHARSET`

3.0

* `DEFAULT_CONTENT_TYPE`

2.1

* `USE_ETAGS`

1.10

* `LOGOUT_URL`
* `ALLOWED_INCLUDE_ROOTS`
* `TEMPLATE_CONTEXT_PROCESSORS`
* `TEMPLATE_DEBUG`
* `TEMPLATE_DIRS`
* `TEMPLATE_LOADERS`
* `TEMPLATE_STRING_IF_INVALID`

1.8

* `SEND_BROKEN_LINK_EMAILS`
* `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Natalia Bidart):

Adding to the above, one obvious candidate I see missing is the set of
`DATABASE_*` settings. I think another key file to inspect is
`docs/internals/deprecation.txt`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:7>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Derek Bantel):

In the forum discussion for this ticket, it seems to have someone working
on it. If that is not true could this ticket be assigned to me?
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:8>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim Graham):

While I see some benefit of the proposed check, it's also possible for
users to define their own custom settings. Thus, I'm not sure it's
reasonable to disallow these names for the rest of time.
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:9>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Ronny Vedrilla):

Hi there! I created the first PR, thx Adam for your list. I asked GPT as
well and came up with a list, which we have do double-check. Furthermore,
it might be a good idea to go back until v1? After all, it's Django,
right?
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:10>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: (none)
Papastefanos |
Type: New feature | Status: new
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Ronny Vedrilla):

@Tim: You are right and we talked about that. But since maintenance is a
huge thing in a softwares lifecycle, all the help you can get is a huge
plus IMHO.

Therefore I argue in favour of somehow "disencouraging" variables that
were already used by the framework. If someone really insists on naming a
variable this way (why should you have such a strong opinion about it?),
you can still disable the check, right?
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:11>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------

Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned

Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Clifford Gama):

* owner: (none) => Ronny Vedrilla
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:12>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Ronny Vedrilla):

@Derek Bantel: I've started working on it but need some support. If you
want to join, please, feel free to do so 🙂
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:13>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Derek Bantel):

Replying to [comment:13 Ronny Vedrilla]:

> @Derek Bantel: I've started working on it but need some support. If you
want to join, please, feel free to do so 🙂

Will do thanks, Ronny.
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:14>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Ronny Vedrilla):

We came up with a first version. Would be happy about some more
thoughts/reviews 🙂
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:15>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Ronny Vedrilla):

* has_patch: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:16>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 1 | Needs documentation: 1

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* needs_docs: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:17>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Ronny Vedrilla):

* needs_docs: 1 => 0

Comment:

Added new feature to 5.2 release notes
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:18>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim Graham):

I remain unconvinced that this is a wise change. Are we going to document
an ever growing list of
[https://docs.djangoproject.com/en/dev/topics/settings/#creating-your-own-
settings a disallowed settings names]? Disallowing something so generic as
`LOGOUT_URL` seems like it will cause unneeded annoyance.

Although the check could be disabled (usage of one disallowed setting
requires disabling the check completely), this is more of a backward-
incompatible change than a new feature.

We have had
[https://github.com/django/django/commit/6192bffb130132461e55e5fe7a7eaaa9a166d08f
temporary compatibility checks] to point out deprecated settings. I guess
that may have been more visible than a deprecation warning in the case of
`DEFAULT_FILE_STORAGE`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:19>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Natalia Bidart):

Replying to [comment:19 Tim Graham]:

> I remain unconvinced that this is a wise change. Are we going to
document an ever growing list of
[https://docs.djangoproject.com/en/dev/topics/settings/#creating-your-own-
settings a disallowed settings names]? Disallowing something so generic as
`LOGOUT_URL` seems like it will cause unneeded annoyance.
>
> Although the check could be disabled (usage of one disallowed setting
requires disabling the check completely), this is more of a backward-
incompatible change than a new feature.
>
> We have had
[https://github.com/django/django/commit/6192bffb130132461e55e5fe7a7eaaa9a166d08f
temporary compatibility checks] to point out deprecated settings. I guess
that may have been more visible than a deprecation warning in the case of
`DEFAULT_FILE_STORAGE`.

Hey Tim, thank you for sharing your thoughts. I appreciate your
engagement. However, I want to clarify that the change was discussed and
agreed upon in the Django Forum, which is where these conversations
typically take place. The audience for ticket comments is smaller, so I
encourage you to continue the discussion in the forum. This way, we can
follow the usual process and involve more people in the conversation.

Personally, I believe practicality beats purity, and in this case, the
benefits of letting users know outweigh any potential issues with someone
who chose to use a setting name that was deprecated by Django. Having said
that, I agree that we should consider a way to ignore a subset of
deprecated setting names. I'll consider this when reviewing the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:20>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* needs_better_patch: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:21>

[Django]

#35674: Provide a check for settings removed (post deprecation)
-------------------------------------+-------------------------------------
Reporter: Serafeim | Owner: Ronny
Papastefanos | Vedrilla
Type: New feature | Status: assigned
Component: Core (System | Version: 5.1
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Ülgen Sarıkavak):

* cc: Ülgen Sarıkavak (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/35674#comment:22>