django-assets and testing

[miracle2k]

As it relates to #3, #30 and other tickets, I've collected some thoughts on unit-testing.

The problem currently, as I understand it, is:

• We use Django finders in development (= debug mode), because we don't want to require collectstatic to be called.
• During testing, Django sets DEBUG=False, so currently they aren't used.
• This is a problem because now django-assets tries to build as if in production, but "collectstatic" obviously doesn't run during tests.

How should django-assets behave in tests? We may want to document this.

1. The user may not want to test assets building at all. They should be able to say ASSETS_AUTO_BUILD=False, and bypass building completely.
2. The user does want to build during tests. In that case, the staticfile finders need to be enabled. Making their use during tests dependent on ASSETS_DEBUG doesn't seem good enough; by setting ASSETS_DEBUG=True you are now only building the parts that ignore the debug mode (i.e. compilers like CoffeeScript), but you are not running the full build during the test.

All that said, ASSETS_DEBUG does seem to be the better hook; it means I want to run from source, and that means it shouldn't require collectstatic to copy the source file to somewhere else first.

[dan-passaro]

Is there a reason usage of staticfiles is dependent on either ASSETS_DEBUG or DEBUG? Why not just have it on all the time?

This currently makes it a bit of a pain to easily test that django-assets does the right thing when developing locally. With ASSETS_DEBUG = True, django-assets just puts the files directly onto the page, which means I'm not getting to double check that there's no problem when my source goes through the filters. However with ASSETS_DEBUG = False, I now have to collectstatic and asset build every time I change my source file, which adds a TON of overhead. Or I have to move my source file to my STATIC_ROOT and develop it there, which is a kind of dirty way to work around the problem.

EDIT:

It'd be much easier if there was a separate setting like ASSETS_USE_STATICFILES that I could just set to False in my production settings file. Does that sound like an acceptable change?

EDIT II:

Upon testing it seems in my case that it's safe to simply always use the staticfiles integration if staticfiles is installed. In production I generate a manifest file, AFAICT having ASSETS_URL_EXPIRE and ASSETS_MANIFEST = 'file' will cause webassets to generate URLs based on the manifest file, so it won't actually run through the static files. And with staticfiles always active, assets build can work even before collectstatic is run.

[miracle2k]

Thinking about it, turning them always on might be the best option. I can't really think of a good reason. The original impetus was probably an attempt to enforce the "collectstatic" workflow, since that is what is required in Django. In Django, you cannot rely on staticfiles in production either, I think.

AFAICT having ASSETS_URL_EXPIRE and ASSETS_MANIFEST = 'file' will cause webassets to generate URLs based on the manifest file

This should all be documented better, since the process involves depends on quite a few factors and seems hard to reason about.

1. When asked to output a url, we check "auto_build". If disabled, the url will be generated from the manifest without touching the filesystem at all.
2. If it is enabled, we will always stat the output file and the input files, to compare timestamps, in case something changed.
3. If something changed, we rebuild.
4. If nothing changed, we generate the url. If there is a manifest, the version is taken from there. If not, the output file is read to hash it.

In other words, to get the full benefit of a manifest, turn of auto building. Otherwise, the timestamps will still be checked.