New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
hobbsd opened this Issue Apr 8, 2015 · 16 comments

Comments

Projects
None yet
3 participants
@hobbsd

hobbsd commented Apr 8, 2015

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

This comment has been minimized.

hobbsd commented Apr 8, 2015

It happens with Django 1.7.7, too.

@Naatan

This comment has been minimized.

Member

Naatan commented Apr 13, 2015

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

@hobbsd

This comment has been minimized.

hobbsd commented Apr 13, 2015

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 %}

screen-2015-04-13_12-28

@Naatan

This comment has been minimized.

Member

Naatan commented Apr 13, 2015

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

This comment has been minimized.

hobbsd commented Apr 13, 2015

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

This comment has been minimized.

Member

Naatan commented Apr 13, 2015

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.

@Naatan Naatan added the Type: Bug label Apr 13, 2015

@Naatan Naatan added this to the 9.1 milestone Apr 13, 2015

@hobbsd

This comment has been minimized.

hobbsd commented Apr 13, 2015

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

This comment has been minimized.

hobbsd commented Apr 14, 2015

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.

@Naatan Naatan modified the milestones: 9.1, 9.1.1 May 19, 2015

@Naatan Naatan modified the milestones: 9.1.1, 9.2 Jun 23, 2015

@Naatan Naatan changed the title from Django 1.8 syntax checking fails w/ ImportError: No module named django.template to Django syntax checking doesn't support Python 3 Jun 23, 2015

@Naatan Naatan modified the milestones: 9.3, 9.2 Jun 23, 2015

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 9, 2015

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.

@mitchell-as mitchell-as modified the milestones: Backlog, 9.3 Oct 9, 2015

@mitchell-as mitchell-as changed the title from Django syntax checking doesn't support Python 3 to Django syntax checking doesn't support Python 3 natively (requires workaround) Oct 9, 2015

@hobbsd

This comment has been minimized.

hobbsd commented Oct 10, 2015

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

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 12, 2015

Thanks for the suggestion. I will look into this.

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Nov 25, 2015

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

@hobbsd

This comment has been minimized.

hobbsd commented May 25, 2016

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

This comment has been minimized.

hobbsd commented May 26, 2016

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

@hobbsd

This comment has been minimized.

hobbsd commented May 26, 2016

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

This comment has been minimized.

Member

Naatan commented May 27, 2016

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

Yes, please open a new ticket :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment