1

When trying to use Tox to better streamline testing across multiple environments, I'm runing into the following error when testing for Python 3.4:

ImportError: No module named 'debug_toolbar'

However, django-debug-toolbar==1.3.0 is listed in my requirements.txt file, and my tox.ini file looks as follows:

[tox]
envlist = py27,py34
skipsdist = True

[testenv]
deps = -r{toxinidir}/requirements.txt
setenv =
    PYTHONPATH = {toxinidir}:{toxinidir}
commands = python manage.py test

It seems as if it is not properly installing the requirements.. Oddly enough, the py27 environment does not throw this error, and is able to perform the tests just fine.

What could be causing this?

EDIT: for reference, here's my current setup. When I run tox the first time (i.e. without .tox), it works fine, but any times after that it fails. The .tox directory does seem to get build up correctly; all dependencies are installed in .tox/py34/lib/python3.4/site-packages. Compared to earlier, I now also uninstalled django, and indeed that is now the first dependency that fails.

(venv)joost@thorin:myproject/ (master✗) % rm -rf .tox
(venv)joost@thorin:myproject/ (master✗) % cat tox.ini
[tox]
envlist = py27,py34
skipsdist = True

[testenv]
deps = -r{toxinidir}/requirements.txt
commands = python manage.py test


(venv)joost@thorin:myproject/ (master✗) % tox
py27 create: /Users/Joost/myproject/.tox/py27
py27 installdeps: -r/Users/Joost/myproject/requirements.txt
py27 runtests: PYTHONHASHSEED='4248725049'
py27 runtests: commands[0] | python manage.py test
Creating test database for alias 'default'...
................
----------------------------------------------------------------------
Ran 16 tests in 0.093s

OK
Destroying test database for alias 'default'...
py34 create: /Users/Joost/myproject/.tox/py34
py34 installdeps: -r/Users/Joost/myproject/requirements.txt
py34 runtests: PYTHONHASHSEED='4248725049'
py34 runtests: commands[0] | python manage.py test
Creating test database for alias 'default'...
................
----------------------------------------------------------------------
Ran 16 tests in 0.093s

OK
Destroying test database for alias 'default'...
____________________________________________________________________ summary _____________________________________________________________________
  py27: commands succeeded
  py34: commands succeeded
  congratulations :)


(venv)joost@thorin:myproject/ (master✗) % tox
py27 runtests: PYTHONHASHSEED='3259360769'
py27 runtests: commands[0] | python manage.py test
Creating test database for alias 'default'...
................
----------------------------------------------------------------------
Ran 16 tests in 0.088s

OK
Destroying test database for alias 'default'...
py34 runtests: PYTHONHASHSEED='3259360769'
py34 runtests: commands[0] | python manage.py test
Traceback (most recent call last):
  File "manage.py", line 8, in <module>
    from django.core.management import execute_from_command_line
ImportError: No module named 'django'
ERROR: InvocationError: '/Users/Joost/myproject/.tox/py34/bin/python manage.py test'
____________________________________________________________________ summary _____________________________________________________________________
  py27: commands succeeded
ERROR:   py34: commands failed
(venv)joost@thorin:myproject/ (master✗) % 
Joost
  • 4,094
  • 3
  • 27
  • 58

3 Answers3

2

In the end, this was solved by upgrading tox. I'm not sure yet when this was fixed exactly, or what bug it was listed as, but using version 2.1.1 I do not get this error any longer.

Joost
  • 4,094
  • 3
  • 27
  • 58
0
File "/usr/local/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line

It looks to me like your Django is not installed inside of a virtualenv. If it were, it would point to /Users/$USER/path/to/virtualenv/lib/python3.4/site-packages/django/etc/etc/etc. Did you somehow set up tox to use the locally installed Django rather than the Django installed inside of the virtualenv?

  • Yeah, that has me wondering as well.. I have not configured tox in any way other than listed in `tox.ini`, and do not see why it would not stay within the virtual env that it should create using `requirements.txt`.. The odd thing is that it does work for Python 2.7. I uninstalled Django locally now, and then the error I get is `ImportError: No module named 'django'` – Joost May 07 '15 at 12:59
  • Try removing `skipsdist = True` from your tox.ini. Maybe that is preventing Django from being installed, if Django is an `sdist`? Also, try running the tox once, then look inside of the `.tox` folder for the Python 3 virtualenv, and see whether it has any packages installed. – Carmen Bianca Bakker May 07 '15 at 13:06
  • As an aside, your `setenv = PYTHONPATH = {toxinidir}:{toxinidir}` refers to `{toxinidir}` TWICE. The colon is a separation character. Ideally, you'd want to point only to `{toxinidir}`, or to that directory as well as `{toxinidir}/your-module-name`. – Carmen Bianca Bakker May 07 '15 at 13:18
  • I got these configurations from [here](http://blog.schwuk.com/2014/03/19/using-tox-django-projects/). You make a valid point about `setenv`. Without `skipsdist`, it gets stuck looking for `setup.py`. --However, I tried to remove `.tox` entirely and started over, and now it suddenly works. I'm not sure what happened there.. perhaps an earlier attempt was interfering. Thanks!-- EDIT: False alarm. When I call `tox` again, I run into the same situation. It did run succesfully _once_ though. – Joost May 07 '15 at 13:22
  • I did some testing, and I discovered that you should delete your `.tox` directory every time you change your requirements.txt. In my minor testing, it would only install packages from requirements.txt on the first run. To verify, make sure that your packages are indeed in `.tox/py34/lib/python3.4/site-packages`. – Carmen Bianca Bakker May 07 '15 at 13:43
  • The first run is fine, and it does indeed install packages in `.tox/py34/lib/python3.4/site-packages`. Subsequent runs fail, however :( – Joost May 07 '15 at 21:01
  • That's queer. Can you post the full output of tox in your original question: once when it runs fine, and once when it breaks? You can shave off some of the stuff here and there, but I'd rather work with too much output than with too little. – Carmen Bianca Bakker May 07 '15 at 22:25
  • I realised I hadn't checked into this for a bit. Do you see anything striking from the output? There is very little to go on.. – Joost May 25 '15 at 14:45
0

I now also uninstalled django, and indeed that is now the first dependency that fails.

It seems that tox creates the virtualenv only once. If it did that, and you afterwards e.g. altered the requirements.txt file, or uninstalled a library like django, you need to re-create it:

To force tox to recreate a (particular) virtual environment:

tox --recreate -e py34  # [edited to py34]

would trigger a complete reinstallation of the existing py27 environment (or create it afresh if it doesn’t exist).

copy of https://stackoverflow.com/a/50199089/1587329, edited to fit

serv-inc
  • 35,772
  • 9
  • 166
  • 188