We Keep Coding

Why Django template loader is case-sensitive in production but not in development

I'm using manage.py runserver on a MacOs Catalina OS as development. I have some templates that fit my built-in class based views. For example:
CuadroDeControl_detail.html LoteDeMedio_list.html TipoDeMedio_detail_tablaCuadros.html
CuadroDeControl_detail_resumen.html LoteDeMedio_list_tabla.html TipoDeMedio_list.html
CuadroDeControl_detail_tablaMetodos.html MetodoDeControl_detail.html TipoDeMedio_list_tabla.html
LoteDeMedio_confirm_delete.html MetodoDeControl_detail_resumen.html dropdown_CuadroDeControl.html
LoteDeMedio_create.html TipoDeMedio_confirm_delete.html dropwdown_CuadroDeControl.html
LoteDeMedio_detail.html TipoDeMedio_detail.html
LoteDeMedio_detail_resumen.html TipoDeMedio_detail_resumen.html
Here is an example of a working view:
class TipoDeMedioDetailView(AreaCalidadMixin, DashboardMixin, DetailView):
model = TipoDeMedio
Note that my views do not explicitly set template_name. In my production
environment, all my views load just fine. Django's template loader knows that the corresponding template to the view is TipoDeMedio_detail.html
However, in my production environment, which is set up with apache2 and mod_wsgi on a Ubuntu 20.04.2 LTS x86_64 Linode VM, the template loader fails to load the template of the same view, because it searches for it in all lowercase. Here is an example:
Request Method: GET
Request URL: http://45.79.4.38/calidad/TipoDeMedio/lista
Django Version: 3.1.6
Exception Type: TemplateDoesNotExist
Exception Value:
calidad/tipodemedio_list.html
Exception Location: /home/jonatan/django-app/venv/lib/python3.8/site-packages/django/template/loader.py, line 47, in select_template
Python Executable: /home/jonatan/django-app/venv/bin/python
Python Version: 3.8.5
Python Path:
['/home/jonatan/django-app/mysite',
'/usr/lib/python38.zip',
'/usr/lib/python3.8',
'/usr/lib/python3.8/lib-dynload',
'/home/jonatan/django-app/venv/lib/python3.8/site-packages']
Server time: Mon, 21 Jun 2021 18:24:19 -0500
Template-loader postmortem
Django tried loading these templates, in this order:
Using engine django:
django.template.loaders.filesystem.Loader: /home/jonatan/django-app/mysite/templates/calidad/tipodemedio_list.html (Source does not exist)
django.template.loaders.app_directories.Loader: /home/jonatan/django-app/mysite/login/templates/calidad/tipodemedio_list.html (Source does not exist)
django.template.loaders.app_directories.Loader: /home/jonatan/django-app/venv/lib/python3.8/site-packages/django/contrib/admin/templates/calidad/tipodemedio_list.html (Source does not exist)
django.template.loaders.app_directories.Loader: /home/jonatan/django-app/venv/lib/python3.8/site-packages/django/contrib/auth/templates/calidad/tipodemedio_list.html (Source does not exist)
An easy fix is to manually specify my template_name attribute on each of my CBV and point to the correct case-sensitive template name (for instance TipoDeMedio_detail.html. However, I would really like to avoid that.
I'm just trying to understand what is the root cause of the change in behavior between the environments. It just leads me to believe I will encounter similar problems in other aspects of Django's behavior.

The default Apple File System (APFS) is not case sensitive. This means that during development on your Mac, Django was able to find templates even if the filenames used incorrect case.
Now that you have moved to Ubuntu, it uses a case-sensitive file system by default. Django is not able to find the templates if the case is wrong.
Note that the Django docs for class-based generic views state:
... in the absence of an explicit template Django will infer one from the object’s name ... is the lowercased version of the model’s name.
The preferable solution is to rename your templates using lowercase.

MattRowbum pointed out to me APFS isn't case sensitive. I consider this sufficient explanation for the change in behavior.

Why newly created project doesn't display built-in API Django documentation?

I have a problem described in this post I have no idea what is the reason of the problem so I decided to create a new project both in Docker like without it. In both cases I get the same problem. To wit to newly created project I add only to urls.py:
from rest_framework.documentation import include_docs_urls
API_TITLE = 'API title'
API_DESCRIPTION = '...'
urlpatterns = [
url(r'^docs/', include_docs_urls(title=API_TITLE, description=API_DESCRIPTION))
]
and in Docker requirements.txt I add coreapi. In case of project without Docker I install via virtualenv pip3 install coreapi. That is all what in my opinion I should do in order to get a view like at the top of this site from documentation Obviously at http://localhost:8000/docs/ However in both cases I get
TemplateDoesNotExist at /docs/
rest_framework/docs/index.html
Django tried loading these templates, in this order:
Using engine django:
django.template.loaders.app_directories.Loader: /usr/local/lib/python3.6/site-packages/django/contrib/admin/templates/rest_framework/docs/index.html (Source does not exist)
django.template.loaders.app_directories.Loader: /usr/local/lib/python3.6/site-packages/django/contrib/auth/templates/rest_framework/docs/index.html (Source does not exist)
(in virtualenv there is only different path)
Does anyone have an idea what might be wrong? If more details will be needed I will add it immediately to this post, just let me know.
UPDATE
When I add rest_framowork to INSTALLED_APPS I get:
AttributeError at /docs/
'NoneType' object has no attribute 'items'
Request Method: GET
Request URL: http://localhost:8001/docs/
Django Version: 1.11
Exception Type: AttributeError
Exception Value:
'NoneType' object has no attribute 'items'
Exception Location: /usr/local/lib/python3.6/site-packages/rest_framework/templatetags/rest_framework.py in items, line 244
Python Executable: /usr/local/bin/python3
Python Version: 3.6.1
Python Path:
['/code',
'/usr/local/lib/python36.zip',
'/usr/local/lib/python3.6',
'/usr/local/lib/python3.6/lib-dynload',
'/usr/local/lib/python3.6/site-packages']
In template /Users/myUser/Projects/DjangoTest/lib/python3.6/site-packages/rest_framework/templates/rest_framework/docs/sidebar.html, error at line 8
UPDATE2
I have in my app on heroku rest_framowork at the top of INSTALLED_APPS however http://myapp.herokuapp.com/docs/ returns:
AttributeError at /docs/
'NoneType' object has no attribute 'items'
Request Method: GET
Request URL: http://myapp.herokuapp.com/docs/
Django Version: 1.11
Exception Type: AttributeError
Exception Value:
'NoneType' object has no attribute 'items'
Exception Location: /app/.heroku/python/lib/python3.6/site-packages/rest_framework/templatetags/rest_framework.py in items, line 244
Python Executable: /app/.heroku/python/bin/python
Python Version: 3.6.1
Python Path:
['/app/Project/backend/project',
'/app/.heroku/python/bin',
'/app',
'/app/.heroku/python/lib/python36.zip',
'/app/.heroku/python/lib/python3.6',
'/app/.heroku/python/lib/python3.6/lib-dynload',
'/app/.heroku/python/lib/python3.6/site-packages']
Server time: Mon, 17 Jul 2017 12:49:49 +0000
SOLTUION
I used djangorestframework==3.6.2 instead of djangorestframework==3.6.3 in requirements.txt. I have no idea why version 3.6.3 doesn't work.

This likely means that you didn't add rest_framework to the INSTALLED_APPS in the settings.py file.

Django, Mezzanine: Autodiscover error, referencing non-existent model

The Django project I'm working on was set up by someone else, prior to me working on it. It has also the Mezzanine component which I'm not familiar with; have not been needing to use it. Suddenly, I have an error which I can't figure out how to fix...
I have an app 'Dashboards' which started off without any models -- models.py was empty, sans the default from django.db import models. Today, I added a model called Banners into it, and I added the admin.py file (as I was intending to use Django's admin module for it). I may have restarted foreman throughout but I never ran any migrations on the model.
Subsequently, I decided to delete the model definitions as well as admin.py, because I decided to create a separate app to handle the specific feature I was working on. After restarting foreman, Django keeps throwing an error:
ImportError at /
No module named banners.models
Request Method: GET
Request URL: http://127.0.0.1:9000/
Django Version: 1.5.5
Exception Type: ImportError
Exception Value:
No module named banners.models
Exception Location: /home/vagrant/www/local/lib/python2.7/site-packages/django/utils/importlib.py in import_module, line 35
Python Executable: /home/vagrant/www/bin/uwsgi
Python Version: 2.7.3
Python Path:
['.',
'',
'/home/vagrant/www/src/django-experiments',
'/home/vagrant/www/src/gargoyle',
'/home/vagrant/www/src/nexus',
'/home/vagrant/www/local/lib/python2.7/site-packages/newrelic-2.6.0.5/newrelic/bootstrap',
'/home/vagrant/www/lib/python2.7',
'/home/vagrant/www/lib/python2.7/plat-linux2',
'/home/vagrant/www/lib/python2.7/lib-tk',
'/home/vagrant/www/lib/python2.7/lib-old',
'/home/vagrant/www/lib/python2.7/lib-dynload',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/home/vagrant/www/local/lib/python2.7/site-packages']
Server time: Tue, 18 Feb 2014 01:13:55 +0000
More specifically, in:
./urls.py in <module>
admin.autodiscover() ...
▶ Local vars
/home/vagrant/www/local/lib/python2.7/site-packages/mezzanine/boot/__init__.py in autodiscover
django_autodiscover(*args, **kwargs) ...
▶ Local vars
I searched all my source, definitely I'm NOT importing 'banners' anywhere. What is the proper way to completely clear it out?

If you are definitely not importing banners anywhere (a search through your codebase should confirm this), then you may have compiled python files still referencing the old stuff.
I can't reproduce exactly what causes this, but I've run into problems like this many times, specifically manifesting in cryptic urls.py import errors.
Try a good old find . -name "*.pyc" | xargs rm
As usual, be very careful with rm commands - never trust it, triple check you wrote *.pyc or have backups / version control.

GAE 1.5.5 local SDK fails to run with python2.7 runtime

GAE 1.5.5 looks to have some excellent, long-waited for features. However, they're not working for me yet.
I've downloaded and installed GAE 1.5.5, and am using a degenerate "AAA" app to test.
Here's roughly my app.yaml (with various changes having been made for testing).
app.yaml
application: AAA # mystical creation.
version: alpha-1
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /media
static_dir: media/
- url: /favicon.ico
static_files: media/images/favicon.ico
upload: media/images/favicon.ico
- url: /admin
script: AAA.app
login: admin
- url: /.*
script: AAA.app
skip_files:
- ^(.*/)?app\.yaml
libraries:
- name: django
version: "1.2"
- name: jinja2
version: latest
- name: yaml
version: latest
I'm running this on Mac OS X Lion (10.7.1).
I hypothesize that I am not actually using the Python 2.7 runtime, in spite of the declaration in app.yaml to use it. I'm not quite sure how to validate this theory, but the errors I've encountered are consistent with it. These errors are reproduced below.
Python Path
When Google App Engine's Python Path is not set, the app engine runs
using Python 2.6.6.
To fix this I set Python Path to /usr/bin/python2.7 in the Google App
Engine preferences.
WSGI
I get the following error:
/Applications/GoogleAppEngineLauncher.app/Contents/Resources/
GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/
google/appengine/tools/dev_appserver.py in
GetParentPackage(self=<google.appengine.tools.dev_appserver.HardenedModulesHook
object>, fullname='AAA.app')
2334
2335 if self.find_module(fullname) is None:
=> 2336 raise ImportError('Could not find module %s' %
fullname)
2337
2338 return self._module_dict[parent_module_fullname]
builtin ImportError = <type 'exceptions.ImportError'>, fullname =
'AAA.app'
<type 'exceptions.ImportError'>: Could not find module AAA.app
args = ('Could not find module AAA.app',)
message = 'Could not find module AAA.app'
Where I've tried AAA.app as:
AAA.py:
from google.appengine.dist import use_library
use_library('django', '1.2') # otherwise we still get django 0.96
from django.core.handlers import wsgi
app = wsgi.WSGIHandler()
AAA/__init__.py
# same content as above
AAA/AAA.py
# same content as above
Note that I can continue to run CGI with app.yaml and AAA.py modified,
mutatis mutandis. However doing so nevertheless results in those errors below:
Jinja2
When I run import jinja2 I get an ImportError.
Django2
Without:
from google.appengine.dist import use_library
use_library('django', '1.2')
I end up with Django 0.96.
Theory
Given the following:
http://code.google.com/appengine/docs/python/tools/libraries27.html
states "The use_library() function provided by the
google.appengine.dist package is unavailable in Python 2.7."
use_library works for me
use_library is required because the "libraries: {django: {...,
version: "1.2"}} declaration does not set the django version to 1.2
Only Django 1.2 is included in the Python 2.7 runtime (per the
libraries27.html link above)
I have to manually specify Python 2.7 in the Python Path in order
for GAE to use Python 2.7
WSGI doesn't load the application properly
Jinja2 cannot be imported
I believe I am not really using the Python 2.7 GAE runtime (i.e. the app.yaml declaration is being ignored in the GAE 1.5.5 SDK).
I hope the above is a helpful description, and I'd be grateful for any thoughts as to what may be happening here – and potential solutions.

I'm have the same issue but on Windows, I posted on the Google App Engine forum and here is an official response I got:
The Dev server doesn't support 2.7 yet. Currently the only way to test
2.7 based code is on appengine

You can use the 2.7 runtime with the local SDK, but just not in threadsafe mode, or with your application defined like script: your.app. Instead use script: your_main_script.py.
For jinja2 and webapp2 which aren't available in the SDK, you can download them and place them in the SDK base directory, which is by default added to sys.path.
You won't be able to test the multithreading capabilities, but you can do everything else, and simply make the changes to app.yaml and your_main_script.py before you deploy.
EDIT: Also, I had to do os.environ[u'APPENGINE_RUNTIME'] = u'python27' in my your_main_script.py, to force the SDK to use webapp2.

Allbuttonspressed has recently posted this handy guide;
you can rundev_appserver on Python27 with threadsafe set to yes.

ImproperlyConfigured: Error importing middleware django.middleware.common: "No module named _md5"

I am running Apache2 on Ubuntu 9 with python 2.6.2 installed. I get the following error when I try to access a page on my django application:
File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/base.py", line 42, in load_middleware raise exceptions.ImproperlyConfigured('Error importing middleware %s: "%s"' % (mw_module, e))ImproperlyConfigured: Error importing middleware django.middleware.common: "No module named _md5"
Here is my wsgi file:
import os, sys
sys.path.append('/etc/apache2/sites-available/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'dynamicuddi.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
From what I've read I think it's a python path problem but I haven't seen an actual solution to this that has worked. Any ideas?
Thanks in advance.

Try to append to python path you project directory and parent one
sys.path.append('path_to_dynamicuddi_project')
sys.path.append('path_to_dynamicuddi_parent_dir')

I don't think this is a pathing issue, like the one here.
I think it's finding the django.middleware.common module just fine and attempting to import it, but that module is causing an ImportError by trying to import "_md5."
You might want to have a look at this rather lengthy thread where Graham Dumpleton attempts to address this very problem: http://www.mail-archive.com/django-users#googlegroups.com/msg30630.html
Failing that, I would recommend you post the contents of the MIDDLEWARE_CLASSES tuple from your settings.py.
Also, what version of Django are you running?

So to wrap this up, we ended up re-installing the OS. I know this is a cop out but it fixed the problem for us.
Thanks for everyone's help!