In fresh-start, django-staticfiles app vs. django.contrib.staticfiles

32 views
Skip to first unread message

limist

unread,
Jun 2, 2011, 11:31:15 AM6/2/11
to pinax-c...@googlegroups.com
Hi Pinax devs,

I was looking at the changes in requirements.txt for various projects in the fresh-start branch, and tried upgrading an existing project of mine to use the newer version of django-staticfiles, 1.0.1.  After renaming some directories and templates, and looking up the new settings variables needed, and tweaking urls.py, I wondered: Is there a compelling reason to continue to have the django-staticfiles external dependency, instead of using the almost-identical django.contrib.staticfiles now in Django 1.3?  

I'm guessing the reason is that the app/1.0.1 version has the LegacyAppDirectoriesFinder (currently, django.contrib.staticfiles does not have that) for older apps that Pinax relies on, that still use a media/ directory instead of the new standard static/ naming convention.  If so, it would be good to hear a core dev confirm this please.  

As it stands there's definitely room for confusion, e.g. in the site-wide urls.py, if one has dynamically generated content (from apps like photologue) that needs to be served with the dev-server/runserver, one needs to use:

from django.conf.urls.static import static   # Note that staticfiles.urls version of static currently fails with document_root kwarg
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Also, the previous pattern in urls.py of,

if settings.SERVE_MEDIA:
    urlpatterns += patterns("",
        (r"", include("staticfiles.urls")),
        )

...doesn't help with serving such media files as it used to, one needs the explicit static() call above.

Thanks.
Reply all
Reply to author
Forward
0 new messages