Add timezone setting along with menu of choices at project creation #139
Conversation
These were taken from https://github.com/dmfilipenko/timezones.json/blob/master/timezones.json, with `America/New_York` moved to the head of the list to serve as the default.
{{ cookiecutter.project_slug }}/{{ cookiecutter.pkg_name }}/settings.py
Outdated
Show resolved
Hide resolved
| @@ -18,6 +18,9 @@ class {{ cookiecutter.pkg_name.split('_')|map('capitalize')|join('') }}Mixin(Con | |||
|
|
|||
| BASE_DIR = Path(__file__).resolve(strict=True).parent.parent | |||
|
|
|||
| USE_TZ = True | |||
| TIME_ZONE = '{{ cookiecutter.timezone }}' | |||
There was a problem hiding this comment.
This is set explicitly upstream: https://github.com/girder/django-composed-configuration/blob/e65bdc513d74ead19035a837079dad6df5ddf48c/composed_configuration/_django.py#L83
At a minimum, if we agree that "America/New_York" is a better default than "UTC", we can just change that upstream.
Furthermore, I agree that timezone may be a common thing which individual projects want to override. As a less disruptive change, which would not require a new cookiecutter option, we could just turn this line into a code comment, which would inform downstreams that they could trivially override the TIME_ZONE for their local project. The benefit is that it would defer this choice (which is not absolutely essential to starting up a working project) to a later point in the lifecycle, while still providing a hopefully-obvious pointer to one of the first settings which developers may actually want to override.
While we're on the subject, we should perhaps think of other settings that it's highly likely developers want to override, and put pointers to them in here too.
There was a problem hiding this comment.
As a short term action item, should I just close this PR and open a one-line-change PR in django-composed-configuration?
As a longer term thing, how do I learn about the relationship between this cookiecutter repo and django-composed-configuration? Is there documentation, or can I just bug you on Slack about it?
There was a problem hiding this comment.
This repo produces a working Django / Girder 4 project. To do that, this repo makes some opinionated choices about the dependencies it uses (including Celery, Django Allauth, etc.)
One of the dependencies is django-composed-configuration, which provides an extensible set of sensible default Django-settings.
Once a project is started, downstreams are free to abandon any or all of default dependencies and it's perfectly possible to "eject" django-composed-configuration by replacing it with a local static list of Django-settings. The advantage to using / keeping django-composed-configuration is that as "best practices" around many Django-settings evolves, downstream projects can get the updates for free, without having to manage hundreds of settings (most of which they aren't opinionated about) explicitly.
As a meta-note about documentation, I think it makes sense to update django-composed-configuration docs to better explain the rationale and value it provides. However, it is ultimately just one library amongst many, and unfortunately, it's probably necessary for developers to have a superficial understanding of almost all the Girder 4 / cookiecutter dependencies and their value proposition in order to successfully further build out a full project.
There was a problem hiding this comment.
As a short term action item, should I just close this PR and open a one-line-change PR in django-composed-configuration?
I think that even if this PR just added a code comment showing how TIME_ZONE could be overridden, it would be a nice net improvement to the cookiecutter.
The bonus would be if someone could figure out a short list of the most immediate settings which projects would want to override.
There was a problem hiding this comment.
I converted the offered setting into an example of how to override, and I'll open a PR to change the default timezone in the other project.
I don't have very much insight into what other settings ought to go here, but I'd like to conclude this work and get it off my plate, so maybe instead we can just open an issue asking for discussion on other settings that should be demo'ed in this fashion.
This reverts commit 40fe0ed. In lieu of forcing this choice at cookiecutter ejection time, it can be optionally overridden manually in the generated settings file.
|
I think that messing with This PR brought up several important issues, which would better be solved in other places:
Accordingly, I'm going to close this PR. Any work on the linked other issues would help to improve overall cookiecutter usability. |
By default, all times in the Django admin console are reported in UTC, which got annoying for me while I was debugging. This PR adds an option at app creation time to select a time zone (
America/New_Yorkby default), which solves the problem for me.Though I took the list of time zones from what looks like a reputable source (https://github.com/dmfilipenko/timezones.json/blob/master/timezones.json), there are so many options that it sort of wrecks the UX. Looking for feedback here. One simple option would be to pare down the list to the few that we believe are popular with our audience (perhaps just the time zones of the Kitware offices), and then supply a URL where the user can look up others.