It sounds like we have consensus that we can make pytz a required dependency when USE_TZ = True, and clear up the associated documentation.
I think now we should try and find (rough) consensus on whether or not we should have pytz as a required dependency in `install_requires`. > If there is a significant number, and we want to continue to support their use-case, it's a non-zero added burden to require them to pull in a frequently-updated useless dependency. Let's assume there is a reasonable number of deployments with and without timezone support. Even then I'm personally in favour of requiring pytz. django-admin.py startproject defaults to USE_TZ = True which means that new projects that install django, start the project, and then run the internal web server are going to get missing dependency problems. A dependency which, as Donald points out, is universally available and runs very little risk of disrupting an install. It'll also mean that existing projects that upgrade to timezone support do not have any extra dependencies to install, though I admit these kinds of projects are more likely to specifically read the timezone documentation. I think the future of django relies more and more on timezone support. On the other hand we have projects that do not have timezone support. These will usually be older projects rather than newer ones. Having pytz installed isn't going to negatively affect a project (it's a small yet often updating dependency), and it can be uninstalled manually (or django installed with "--no-deps") if it concerns specific deployments. Mainly though, requiring pytz doesn't result in a failure mode for these projects. There is certainly a non-zero cost for these users, but I don't think it's as big as asking users of the default project to manually install a dependency that is required. I think non-timezone users that care whether or not they have pytz installed will be the smallest group of users, and they can install/upgrade Django with the --no-deps flag. Cheers On Tuesday, 17 May 2016 10:21:29 UTC+10, Josh Smeaton wrote: > > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be required for just about every database and platform > combination except postgres on linux. The docs for timezone support ( > https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say: > > Installing pytz <http://pytz.sourceforge.net/> is highly recommended, but >> may not be mandatory depending on your particular database backend, >> operating system and time zone. If you encounter an exception querying >> dates or times, please try installing it before filing a bug. > > > I tried to find some documentation on the broader internet that would more > accurately describe when and for what platforms pytz is actually required > for timezone support, but was unable to find anything. I've opened a new > ticket https://code.djangoproject.com/ticket/26622 to clarify more > explicitly when pytz is required. > > However, I'm wondering if we should just go all-in on pytz and require it > for timezone support. I've not run a Django site with timezone support > without pytz, so I'm not sure what exact limitations exist or why you'd > want to use timezone support without pytz. I'd be interested in hearing use > cases for not requiring pytz if there are any. Explicitly requiring pytz > will make test writing a lot easier, and will remove any doubt about > whether or not pytz is required for users. > > Josh > -- 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+unsubscr...@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/b72517fa-03ce-4585-853a-2a0c86757fa3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
