InternalError and AssertionError with non-django tests

[klvbdmh]

After installing pytest-django I cannot run my old tests on a simple scrapper. The scrapper's project consists of five files: __init__.py, scrap.py, test_scrap.py, output.txt, and test.txt. The test works by comparing the two text files. As you can see it's a very simple project and it doesn't use django at all.

When I run test_scrap.py with pytest I get the following error:

INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\main.py", line 80, in wrap_session
INTERNALERROR>     config.do_configure()
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\config.py", line 618, in do_configure
INTERNALERROR>     self.hook.pytest_configure(config=self)
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\core.py", line 413, in __call__
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\core.py", line 424, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\core.py", line 315, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\pastebin.py", line 14, in pytest_configure
INTERNALERROR>     __multicall__.execute()
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest-2.6.4-py3.4.egg\_pytest\core.py", line 315, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest_django-2.7.0-py3.4.egg\pytest_django\plugin.py", line 203, in
pytest_configure
INTERNALERROR>     if django_settings_is_configured():
INTERNALERROR>   File "C:\Python\lib\site-packages\pytest_django-2.7.0-py3.4.egg\pytest_django\lazy_django.py", line 26,
 in django_settings_is_configured
INTERNALERROR>     assert settings.configured is True
INTERNALERROR> AssertionError: assert <django.conf.LazySettings object at 0x0361D930>.configured is True

Tests in a separate django project work with no problems after following the configuration procedure. It's just non-django projects I have problems with.

I'm using the latest stable versions of both pytest and pytest-django, Python 3.4, and Windows 7.

After uninstalling pytest-django plugin my non-django scrapper test works again.

[klvbdmh]

On further research, manually deactivating the plugin with a parameter -p no:django seems to work.

[blueyed]

I still consider this a bug with pytest-django - re-opening.

[rob-b]

I think that this bug is related to not setting --ds or DJANGO_SETTINGS_MODULE

[blueyed]

I think that this bug is related to not setting --ds or DJANGO_SETTINGS_MODULE

Why would you want to do this for a non-Django project?

I think that django_settings_is_configured should return False, if either DSM/--dsm or django is not imported (not and) (https://github.com/pytest-dev/pytest-django/blob/master/pytest_django/lazy_django.py#L17-L21).

Changing this breaks some existing tests however.

[blueyed]

The issue can be reproduced by just installing the following packages alongside:

% pip install django pytest pytest-django pytest-splinter

Then even py.test -h will fail, which should never happen!

As far as I can see it's caused by pytest-splinter importing "django" when
setting up its drivers, and then pytest-django assuming that Django is
configured.

[pelme]

Importing things from Django without having called django.setup() before is not supported by Django: #119 (comment) "django.setup() should run before anything else and especially before other imports."

pytest-django must be the first to import Django and call django.setup(), and therefore django must not be loaded at import time by other pytest plugins (directly or indirectly).

We should probably introduce an assertion "assert 'django' not in sys.modules" right before pytest-django imports django and calls setup() to fail explicitly with a proper error message.

I did a quick hack to delay the Django import in splinter and it solved the problem. I think it makes sense for splinter to delay imports of Django, Zope and Flask anyways until they are actually requested. pytest-splinter could also be changed to delay the import of splinter into hooks.

Tricky issue, what are your thoughts?

[blueyed]

Just importing "django" for detecting if it's installed, like pytest-splinter does, is supported by Django, isn't it?

django_settings_is_configured could be made to look for django.conf in sys.modules instead.
Is there something more specific / fitting?

I've gave it a shot in ac2b3c7.

[pelme]

You are right, import django or from django import setup should be safe (otherwise using Django would be very hard: it is kind of hard to call django.setup() if you are not allowed to import it. :-)

I didn't notice that splinter actually deferred the other imports (importing Client), so the problem does not lie in splinter or pytest-splinter.

[blueyed]

So #200 makes sense?
Is there something better to test for than django.conf?

[pelme]

It looks very good, feel free to merge! Good job tracking this down, these issues are very "interesting" :)

I am not sure, django.core and django.utils would be candidates to look at I guess? Both are imported from django.conf. Or maybe just check all of them?

OTOH, as long as django.conf is not imported everything should be fine I guess? Models, ORM, templates and databases all heavily depend on settings, so they would import django.conf from what I can tell from a quick skim from the Django source. If someone manages to import something from somewhere in django.utils that does not depend impliclty on django.conf, it shouldn't really be a problem either way.

Either checks is fine by me :-)

[blueyed]

Squash-merged in 7c84e7f.

@klvbdmh
Could you check / verify that this fixes your issue?

[pelme]

👍

[klvbdmh]

Please excuse my delayed reply.

Yes, I can confirm that this fix has indeed solved my issue.

[blueyed]

Thanks, @klvbdmh.
Closing it as per the last comment.