Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
On Tue, Aug 13, 2013 at 8:01 PM, Ramiro Morales wrote: > > Guys, I've updated the PR with further work on this: > > https://github.com/django/django/pull/1354 FYI This has landed on master with commit: https://github.com/django/django/commit/e909ceae9b3e72b72e0a2baaa92bba9714f18cd2 Regards, -- Ramiro Morales @ramiromorales -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
On Mon, Jul 15, 2013 at 1:16 PM, Ramiro Morales wrote: > [...] > > I will be working further on the PR keeping all this design advice in > mind. Guys, I've updated the PR with further work on this: https://github.com/django/django/pull/1354 Any feedback is welcome. Thanks, -- Ramiro Morales @ramiromorales -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
Hi, On Jul 15, 2013, at 9:22 AM, Carl Meyer wrote: > On 07/14/2013 07:16 AM, Jannis Leidel wrote: >> 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. > > This advice makes a lot of sense to me. I think we should be able to > make the staticfiles integration pretty easy; i.e. just have a subclass > of LiveServerTestCase that lives in django.contrib.staticfiles that > adjusts the behavior to use the full staticfiles finders, where the base > LiveServerTestCase in core just serves from STATIC_ROOT. I think that's a great idea. This way, all you'd need to do to have the full static finders is make your TestCase inherit from that subclass, and there would be no need to ever run collectstatic while running your tests. Julien -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
Hi Jannis and Ramiro, On 07/14/2013 07:16 AM, Jannis Leidel wrote: > 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. This advice makes a lot of sense to me. I think we should be able to make the staticfiles integration pretty easy; i.e. just have a subclass of LiveServerTestCase that lives in django.contrib.staticfiles that adjusts the behavior to use the full staticfiles finders, where the base LiveServerTestCase in core just serves from STATIC_ROOT. Carl -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
Hi Jannis, Thanks for your reply, On Sun, Jul 14, 2013 at 10:16 AM, Jannis Leidel wrote: > > 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 **shouldn't** make > the FSFilesHandler a new core component but just a implementation > detail. It would support it and the staticfiles handler but I agree with you on that we should not be shipping something like FSFilesHandler or at least should move it near where it's used and/or marking/documenting it as internal. > >> 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. Ah yes, sorry for not making the PR more granular commit-wise. This is the staticfiles serve() view: https://github.com/django/django/blob/master/django/contrib/staticfiles/views.py#L20 and this is the new, albeit simplified, duplicate copy: https://github.com/django/django/pull/1354/files#L3R1072 > >> 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 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. I will be working further on the PR keeping all this design advice in mind. Thanks again, > > Jannis > -- Ramiro Morales @ramiromorales -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
On 14.07.2013, at 15:16, Jannis Leidel wrote: > > On 14.07.2013, at 01:41, Ramiro Morales 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 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. > > -- 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.
Re: #20739 - Making LiveServerTestCase not depend on staticfiles?
On 14.07.2013, at 01:41, Ramiro Morales 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.
#20739 - Making LiveServerTestCase not depend on staticfiles?
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. Another change introduced is duplicating (simplifying it slightly) django.contrib.staticfiles.views.serve() view functionality. The last stumbling block we need to remove is use of staticfiles' finders infrastructure, for which I don't have any solution for now. 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. Regards, -- Ramiro Morales @ramiromorales 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.
