[Django] #23899: A new field/doc note in the settings.py to denote django version
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Component: Core (System | Version: master
checks) | Keywords: settings.py, django
Severity: Normal | version
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
A field to know which django version was used to create the project. This
will be helpful while setting up the code in a new environment. Solutions
like requirements.txt do exist, but a quickly accessible variable/ note in
the auto-generated help in the settings.py without a requirements.txt
would make project for self contained.
--
Ticket URL: <https://code.djangoproject.com/ticket/23899>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage:
version | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: => 0
* component: Core (System checks) => Core (Other)
* needs_tests: => 0
* needs_docs: => 0
Comment:
My concern with this idea is that there is nothing enforcing this to be up
to date, whereas that is more the case with requirements.txt. That would
make it very unreliable in practice to indicate which version this project
is supposed to run with. It may be used indicate which Django version's
project template was used to initially create the project, but I'm not
sure what the added value would be. Also, that would be unreliable because
people may assume that should match the running version, and simply update
it with each upgrade.
In other words: as far as I can see there is little added value due to the
low reliability. The recommended way to ensure you are running a
particular version is and has been requirements.txt. But perhaps there's
something I'm overlooking :)
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by carljm):
* stage: Unreviewed => Accepted
Comment:
Generating an actual setting for this is a bad idea, IMO -- too unclear
what effect it would have, too likely to become out of date or be edited
wrongly, and too likely to be used in ways that would cause breakage if
so.
But I could see value in adding a simple comment like `# Generated by
'django-admin.py startproject', Django 1.7.1`, on the general principle
that it's good practice for automatic code generators to insert a
"generated by" comment. That's clearly a "this file generated by", not a
"this project runs with", so it's less likely to be incorrectly edited
(and doesn't really matter that much if it is). There are definitely times
I would have found this useful, just to get a rough idea of which settings
I ought to check for possible updates needed.
Accepting on that basis.
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by freakboy3742):
This would also be useful for upgrade checks. At present, when we do
version change checks (e.g., checks related to TEST_RUNNER) we have to
guess whether the project is "1.5 and has been upgraded" or "1.6 with a
specific collection of settings". There are tickets reporting false
positives related to these checks, which is to be expected, because things
like "User has TEMPLATE_DIRS set" aren't a reliable way to check that
you're running a particular Django version.
Having a setting (or, as Carl suggests, a "meta" setting that is actually
a comment) that represents "This project configuration is known to be
correct for version X" would be very helpful for this purpose. The key
thing here is that it isn't just a "Generated on v1.N" setting, because
you can update the settings over time and know that the settings file is
"good" for v1.(N+1). Being easily machine parseable is also important.
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by carljm):
Hi Russ - I'm not convinced that we should try to use a settings file
marker of any kind for that upgrade-checks purpose, because you still end
up with too many false positives ("yes, my project settings were initially
generated on 1.5, and yes I'm running 1.6, and yes I don't have
TEST_RUNNER set, and yes, my tests are still just fine, thanks for
asking"). My proposal here was really geared towards "possibly
informational for readers, but not intended for machine parsing at all" --
if we're going to bother with machine parsing a comment, why not just make
it a setting?
With the sort of "generated by" comment I'm suggesting here, I'd expect at
least advanced users - myself included - to just remove it once they go
through their settings file and edit it sufficiently that it's now more
"written by me" than "generated by Django". So I wouldn't consider it
something whose presence Django should rely on.
(It's somewhat off-topic for this ticket, but my current feeling about
upgrade checks is that we just simply shouldn't add them at all. People
who upgrade without bothering to even read the backwards-incompatible-
changes section of the release notes make their own bed, they can lie in
it. Checks should only be loud about things that we can confidently say
are a configuration problem given what we know about the current state,
not what we try to infer about whether they might have recently upgraded.)
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by martinblech):
Hello everyone. I have implemented a "Generated by…" notice in this
branch: https://github.com/martinblech/django/tree/ticket_23899
This is my first contribution to Django. I tried to follow the
contribution guidelines, hope I didn't miss anything, but let me know if I
did.
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by carljm):
@martinblech That looks pretty good to me! I don't think new tests are
needed for a change that only impacts a docstring. The next step would be
for you to turn that branch into an actual pull request against the
``django/django`` repo; that way the CI tests will run against it, and
someone can review and mark it Ready for Checkin.
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by martinblech):
@carljm Great! Here's the pull request:
https://github.com/django/django/pull/3613
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: atmb4u | Owner: nobody
Component: Core (Other) | Version: master
Keywords: settings.py, django | Triage Stage: Accepted
version | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"4c123d0f79b3f417ec5b030c616365882e734a1e"]:
{{{
#!CommitTicketReference repository=""
revision="4c123d0f79b3f417ec5b030c616365882e734a1e"
Fixed #23899 -- Added 'Generated by Django X.Y' to startproject template.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23899#comment:8>