Django syntax checking doesn't support Python 3 natively (requires workaround)

[hobbsd]

This error appears in my Django 1.8 project templates on the last {% endblock %} in the file. The Django template highlighting and code completion work, but the linting fails.

[hobbsd]

It happens with Django 1.7.7, too.

[Naatan]

Could you please provide a sample snippet with which we can reproduce your issue?

[hobbsd]

It must be something specific to my system, or it seems like you would've encountered it. For example, this will do it:

{% block test %}
{% endblock %}

[Naatan]

Could it be that something has changed in the latest version of Django, where django.template is no longer a thing/has been renamed to something else?

If not, make sure that the django libraries are on your python path, as the linter seems to depend on these.

[hobbsd]

The project's python has Django installed, and django.template is still there. Could this problem be related to the Python2 vs. Python3 project problem? Python files in a Python3 project aren't correctly linted due to not using the correct Python installation until you flag the file as being Python3 -- maybe the Django linter is incorrectly assuming Python2 and therefore not locating django?

[Naatan]

That's an interesting point, I will verify this.

Are you by any chance working on an open source project? It'd be really useful if I could reproduce this issue on the same project you're using.

[hobbsd]

This project isn't open, but I just reproduced the issue by creating a new project, assigned a Python3 virualenv (with Django 1.7 installed) as the default python, and created a test template same as above.

[hobbsd]

I installed Django into the system Python2, and the error went away. So the Django linter seems to be trying to use Python2 only, which makes sense because there's no way to tell it which python to use. I suppose it could try Python2, and if it doesn't find Django there try Python3.

[mitchell-as]

By default the Django linter uses the Python2 interpreter, as we cannot tell the difference between Python2 and Python3 Django files. A workaround would be to change your Python2 interpreter path to point to your Python3 installation (and ignore the warning). Then you wouldn't have to install Django into your Python2 installation.

Changing this ticket to an enhancement since this issue is really about detecting whether to use the Python2 interpreter vs Python3 interpreter. However, this is not trivial.

[hobbsd]

If Komodo could accept having just one Python interpreter assigned to a project, wouldn't it be trivial?

[mitchell-as]

Thanks for the suggestion. I will look into this.

[mitchell-as]

Easiest solution was to fall back on Python3 interpreter if there was a failure in Python2.

[hobbsd]

Django linting is still broken in Komodo Edit 10. And after looking at the two python modules involved, I can see at least some of the problems.

The djangoLinter module is expecting a tempfile and the Django project's base directory, but koDjango_UDL_Language.py gives it a tempfile and a directory or a string containing the settings module.

If DJANGO_SETTINGS_MODULE is not set in the Komodo environment the koDjango_UDL_Language.py module tries to find a settings.py by looking around in nearby directories and goes with the first one it finds -- usually the wrong one, at least for me.

If DJANGO_SETTINGS_MODULE is set in the Komodo environment, koDjango_UDL_Language.py passes it to the djangoLinter module as if it were the base directory for the project. Then djangoLinter appends ".settings" to the basename of what it thought was a directory, and now "my_project.settings" becomes "my_project.settings.settings", which is just as bad as a settings module of "my_other_project.settings" (as in the previous scenario).

It's not safe to guess at what the settings module will be -- they aren't always going to be "projectname.settings". Just require DJANGO_SETTINGS_MODULE to be set for the project if the user wants Django syntax checking.

Similarly, why jump through hoops (as koDjango_UDL_Language.py does) trying to figure out which python interpreter to use? Just use the one that's set for the project (or the file if its prefs override).

[hobbsd]

Sorry, I just realized maybe I should've opened a new issue for this?

[hobbsd]

I was looking into this a bit, and you don't even need the DJANGO_SETTINGS_MODULE, so all you'd need is the correct python interpreter. In djangoLinter.py (you probably shouldn't bother with a separate djangoLinter3.py, just write the one to be able to accommodate Python 2 & 3), you'd do something like:

def main(argv):
    pathname = argv[1]
    settings.configure()
    try:
        django.setup()
    except AttributeError:
        # We're using Django<1.7
        pass
    return loadTemplate(pathname)

EDIT: I take this back -- DJANGO_SETTINGS_MODULE is required if any non-standard template tags are used via load.

[Naatan]

Sorry, I just realized maybe I should've opened a new issue for this?

Yes, please open a new ticket :)

[tonyattwood]

Yo!

Just look at that great stuff outta here! You're gonna love it, I swear! More info here http://sisirasi.robertsgeo.com/e4hdgw

tony.attwood