A new field/doc note in the settings.py to denote django version

[Anoop Thomas Mathew]

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.

[Sasha Romijn]

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 :)

[Carl Meyer]

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.

[Russell Keith-Magee]

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.

[Carl Meyer]

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.)

[Martín Blech]

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.

[Carl Meyer]

@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.

[Martín Blech]

@carljm Great! Here's the pull request: ​https://github.com/django/django/pull/3613

[Tim Graham <timograham@…>]

In 4c123d0f79b3f417ec5b030c616365882e734a1e:

Fixed #23899 -- Added 'Generated by Django X.Y' to startproject template.