On 14.07.2013, at 15:16, Jannis Leidel <[email protected]> wrote: > > On 14.07.2013, at 01:41, Ramiro Morales <[email protected]> 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.
Sorry I meant "we **shouldn't** make the FSFilesHandler a new core component but just a implementation detail". Jannis >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
