On 14.07.2013, at 01:41, Ramiro Morales <cra...@gmail.com> wrote: > Hi all, > > Ticket [1]8713 is tracking removing dependency of Django core on contrib > apps code. > > One of the action items enumerated there is the fact that > LiveServerTestCase makes use of django.contrib.staticfiles' facilities. > I've opened ticket [2]20739 for it and have some work in progress on a > [3]PR. > > What I've done so far is move some base functionality of staticfiles' > StaticFilesHandler to a new FSFilesHandler that lives in > django.core.handlers and make both StaticFilesHandler and a new ad-hoc, > private _StaticFilesHandler located in django/test/testcases.py (similar > to the existing _MediaFilesHandler) inherit from it.
I'm pretty sure we don't want to increase the code that deals with serving files. We've repeatedly improved the documentation about helping users to configure their web server to serve the files instead of adding an official file serving WSGI middleware like you propose here. Especially since we already provide a view in django.views.static to serve files I think we need to clarify what the purpose of the FSFilesHandler would be. If there is little good reason (e.g. only supporting LiveServerTestCase) then we should make the FSFilesHandler a new core component but just a implementation detail. > Another change introduced is duplicating (simplifying it slightly) > django.contrib.staticfiles.views.serve() view functionality. Where was that duplicated specifically? Couldn't find it in the pull request. > The last stumbling block we need to remove is use of staticfiles' > finders infrastructure, for which I don't have any solution for now. Maybe the LiveServerTestCase should simply have a generic file serving feature, basically just using the core static view to serve STATIC_ROOT under STATIC_URL. Users that want to continue using staticfiles we could ask to call collectstatic in a setUpClass method in their LiveServerTestCase subclasses. Or just ask them to run it before running the tests. > I'm posting this here to get feedback/help on the approach and more > generally to know your opinions about if the dependency removal is worth > pursuing because, frankly, moving contrib.* code to the core and > duplicating functionality smells a little bit funny to me. Yeah, I can relate to that, it does to me, too. I think decoupling the file serving slightly from how the files got to the place they are served from, is a good first step. The common denominator between the core ability to serve files and staticfiles is the reliance on conventions like STATIC_ROOT and STATIC_URL. If we can backscale LiveServerTestCase to only do the core ability out of the box and document the way to do it the staticfiles way, then I think we're on the right track. Jannis > 1. https://code.djangoproject.com/ticket/8713#comment:13 > 2. https://code.djangoproject.com/ticket/20739 > 3. https://github.com/django/django/pull/1354 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
