Re: Deprecate FCGI support in Django 1.7
If it were just Hostgator that was the problem, that might be a worthwhile approach. But that's not the true scope of the problem. We're talking about every hosting provider in the "$5 per month" hosting category that currently supports PHP, and provides FCGI as the fastest way they can support any other framework without having to think too hard. I'm not arguing that FastCGI is a good option, just that it's prevalent. And if we're going to stop supporting it, we need to be aware of who we're cutting off. Yours, Russ Magee %-) On Mon, Jul 15, 2013 at 1:04 PM, Michael Manfre wrote: > Has anyone thought to contact HostGator and see how they would react to > Django dropping FastCGI and/or whether they would be willing to support a > WSGI option. > > Regards, > Michael Manfre > > > On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> >> On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney < >> cur...@acommoncreative.com> wrote: >> >>> As much as I recognise FastCGI is pretty much a dead technology in the >>> Python world, for people stuck with cPanel sites like HostGator, it still >>> appears to be, pretty much, the only option. >>> >>> And installing uWSGI there is simply not an option there. >>> >>> So unless there's a pure python FastCGI -> WSGI library built that >>> supports Django, we're just closing the door on this avenue... >>> >>> [I say this despite my personal loathing of HostGator... :)] >>> >> >> This would be my concern as well. >> >> I have no love for FastCGI as a platform, but there's a wide range of >> hosting providers out there, especially at the cheap end, that don't >> provide a WSGI option. >> >> The right option here may well be to say "Tough Luck" to these people and >> and encourage them to move to different hosting providers. However, I don't >> want to rush into this decision without considering the effect on the low >> end of our user base. >> >> Yours, >> Russ Magee %-) >> >> -- >> 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. > > > -- 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: Deprecate FCGI support in Django 1.7
Has anyone thought to contact HostGator and see how they would react to Django dropping FastCGI and/or whether they would be willing to support a WSGI option. Regards, Michael Manfre On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney < > cur...@acommoncreative.com> wrote: > >> As much as I recognise FastCGI is pretty much a dead technology in the >> Python world, for people stuck with cPanel sites like HostGator, it still >> appears to be, pretty much, the only option. >> >> And installing uWSGI there is simply not an option there. >> >> So unless there's a pure python FastCGI -> WSGI library built that >> supports Django, we're just closing the door on this avenue... >> >> [I say this despite my personal loathing of HostGator... :)] >> > > This would be my concern as well. > > I have no love for FastCGI as a platform, but there's a wide range of > hosting providers out there, especially at the cheap end, that don't > provide a WSGI option. > > The right option here may well be to say "Tough Luck" to these people and > and encourage them to move to different hosting providers. However, I don't > want to rush into this decision without considering the effect on the low > end of our user base. > > Yours, > Russ Magee %-) > > -- > 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: Deprecate FCGI support in Django 1.7
On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney wrote: > As much as I recognise FastCGI is pretty much a dead technology in the > Python world, for people stuck with cPanel sites like HostGator, it still > appears to be, pretty much, the only option. > > And installing uWSGI there is simply not an option there. > > So unless there's a pure python FastCGI -> WSGI library built that > supports Django, we're just closing the door on this avenue... > > [I say this despite my personal loathing of HostGator... :)] > This would be my concern as well. I have no love for FastCGI as a platform, but there's a wide range of hosting providers out there, especially at the cheap end, that don't provide a WSGI option. The right option here may well be to say "Tough Luck" to these people and and encourage them to move to different hosting providers. However, I don't want to rush into this decision without considering the effect on the low end of our user base. Yours, Russ Magee %-) -- 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: Deprecate FCGI support in Django 1.7
As much as I recognise FastCGI is pretty much a dead technology in the Python world, for people stuck with cPanel sites like HostGator, it still appears to be, pretty much, the only option. And installing uWSGI there is simply not an option there. So unless there's a pure python FastCGI -> WSGI library built that supports Django, we're just closing the door on this avenue... [I say this despite my personal loathing of HostGator... :)] -- Curtis Maloney On 15 July 2013 11:35, gilberto dos santos alves wrote: > i start 2 months ago using fcgi inside an shared host (hostgator.com) > and after lots of tries with wsgi only using fcgi was worked with > apache2. but i will read and learn about uwsgi and try this. my app > use version 1.6a of django is 1.6b worked using python 2.6. because > parts of my app is with status development i will test this with > python 2.7 too. but i agree that docs is not clear, because they mixed > concepts of apache2 and django (directories static, admin etc). i am > reviewing these docs soon for clarify concepts about wsgi, fcgi and if > necessary uwsgi. If someone have advices or additional ref. is > welcome! ;>) > > 2013/7/14 Florian Apolloner : > > Hi, > > > > I'd like to get rid of everything FCGI-specific in Django sooner or later > > (rather sooner). Flup isn't maintained since a long time and there is no > > ticket tracker to report stuff. Graham pointed out that if someone wants > to > > use FCGI they can use > > http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket > > which doesn't even require flup, which sounds like a good compromise to > me. > > I'd need some help for the docs from some uWSGI users, since I have no > idea > > about it ;) > > > > Thoughts, objections? > > > > Cheers, > > Florian > > > > -- > > 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. > > > > > > > > -- > gilberto dos santos alves > +55.11.98646-5049 > sao paulo - sp - brasil > > -- > 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: Deprecate FCGI support in Django 1.7
i start 2 months ago using fcgi inside an shared host (hostgator.com) and after lots of tries with wsgi only using fcgi was worked with apache2. but i will read and learn about uwsgi and try this. my app use version 1.6a of django is 1.6b worked using python 2.6. because parts of my app is with status development i will test this with python 2.7 too. but i agree that docs is not clear, because they mixed concepts of apache2 and django (directories static, admin etc). i am reviewing these docs soon for clarify concepts about wsgi, fcgi and if necessary uwsgi. If someone have advices or additional ref. is welcome! ;>) 2013/7/14 Florian Apolloner : > Hi, > > I'd like to get rid of everything FCGI-specific in Django sooner or later > (rather sooner). Flup isn't maintained since a long time and there is no > ticket tracker to report stuff. Graham pointed out that if someone wants to > use FCGI they can use > http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket > which doesn't even require flup, which sounds like a good compromise to me. > I'd need some help for the docs from some uWSGI users, since I have no idea > about it ;) > > Thoughts, objections? > > Cheers, > Florian > > -- > 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. > > -- gilberto dos santos alves +55.11.98646-5049 sao paulo - sp - brasil -- 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: Spam on ticket #542
On Sun, Jul 14, 2013 at 12:23 PM, Aymeric Augustin wrote: > Hello, > > For some reason, ticket #542 has been collecting spam comments that bypassed > Trac's antispam. Since receiving spam on django-updates and deleting it > manually gets tedious after 100 messages, I hacked Trac to prevent further > comments on this ticket. > > I'm positive that Trac's antispam works in general: the monitoring views > shows that it fends off over 200 spams every day. However, these comments > weren't blocked and they don't appear in the monitoring view. I can't explain > that. Please contact me privately if you can help! Thanks for that, I myself deleted 10+ such comments and was starting to feel like the the dumb side of the battle because the spammer side most surely was a script :) This is what I found: * Feeding the comments contents to our Trac instance Bayes anti-spam component test form says it would be effectively be identified as spam with a 100% confidence score. * Strangely enough, looking at the anti-spam monitoring log, there is no trace of these attempts (what would mean it isn't even detected as a comment worth being analyzed in search of spam), but I saewat least another attempt by another spammer being successfully rejected. Would it be worth look at the web server log to see if these comments were effectively created by HTTP POST requests at all? 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: Spam on ticket #542
On Sun, Jul 14, 2013 at 11:23 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > For some reason, ticket #542 has been collecting spam comments that > bypassed Trac's antispam. Since receiving spam on django-updates and > deleting it manually gets tedious after 100 messages, I hacked Trac to > prevent further comments on this ticket. > > I'm positive that Trac's antispam works in general: the monitoring views > shows that it fends off over 200 spams every day. However, these comments > weren't blocked and they don't appear in the monitoring view. I can't > explain that. Please contact me privately if you can help! > > Thanks for that Aymeric -- I was getting similarly stabby about the comments on that ticket. I also noticed that the comments were bypassing the Akismet spam checks. I have no idea how that is even possible - my concern is that there might be an exploit that we don't know about. Russ %-) -- 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.
Deprecate FCGI support in Django 1.7
Hi, I'd like to get rid of everything FCGI-specific in Django sooner or later (rather sooner). Flup isn't maintained since a long time and there is no ticket tracker to report stuff. Graham pointed out that if someone wants to use FCGI they can use http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket which doesn't even require flup, which sounds like a good compromise to me. I'd need some help for the docs from some uWSGI users, since I have no idea about it ;) Thoughts, objections? Cheers, Florian -- 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.
Spam on ticket #542
Hello, For some reason, ticket #542 has been collecting spam comments that bypassed Trac's antispam. Since receiving spam on django-updates and deleting it manually gets tedious after 100 messages, I hacked Trac to prevent further comments on this ticket. I'm positive that Trac's antispam works in general: the monitoring views shows that it fends off over 200 spams every day. However, these comments weren't blocked and they don't appear in the monitoring view. I can't explain that. Please contact me privately if you can help! Thank you, -- Aymeric. -- 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.