Tests fail if DJANGO_STATIC_NAME_PREFIX or DJANGO_STATIC_SAVE_PREFIX are set

[slinkp]

The test run gives numerous failures if either of those are in your settings.py. This means I can't just do manage.py test; if I want to only see failures I care about, I have to specificy the apps I want to test, and I have a lot of apps in this project.

fwiw my settings are like:

DJANGO_STATIC_NAME_PREFIX = '/cache-forever' DJANGO_STATIC_SAVE_PREFIX = '/tmp/static%s' % DJANGO_STATIC_NAME_PREFIX

[peterbe]

I guess if the unit tests could reset them first it should work.

Thanks for the heads up.

[peterbe]

I can't reproduce this. I created a file called "issue8settings.py" that contained the following:

    from settings import *
    DJANGO_STATIC_NAME_PREFIX = '/cache-forever'
    DJANGO_STATIC_SAVE_PREFIX = '/tmp/static%s' % DJANGO_STATIC_NAME_PREFIX

Then I ran the tests:

    $ ./manage.py test --settings=issue8settings
    Creating test database 'default'...
    No fixtures found.
    .............................................
    ----------------------------------------------------------------------
    Ran 45 tests in 0.081s

    OK

In other words, even if I do set these settings it doesn't break the tests. What kind of errors do you get?

[slinkp]

I can reproduce this pretty reliably with django-static 1.4.0. Here's a gist showing me doing this in a fresh django app in a fresh virtualenv, with attached good and bad settings files. The only difference between the settings files is that one has those variables and one doesn't. https://gist.github.com/720314

The odd thing is that sometimes with the 'bad' settings file in place, the tests pass. If I run them in a loop, they will eventually start failing again:

for i in seq 99999; do echo $i; ./manage.py test django_static || break; done

[peterbe]

Sorry for being dim but the problem here isn't with the DJANGO_STATIC_NAME_PREFIX and DJANGO_STATIC_SAVE_PREFIX settings being available/not available but with the clock issue with discussed in another issue. Right?

[peterbe]

Actually I've discovered a couple of other places where it could fail because of the clock. In those cases I now put in a hacking thing that strips or decrements the last second on the timstamp and tests again. At the time of writing I'm running the whole suite (43 tests) in a loop and it's gone around 378 times without failing.

I'm going to close this one now and push my change. Thanks dude!!

[slinkp]

err yes, sorry i forgot to close this once i figured out the clock problem!