Re: Deprecate FCGI support in Django 1.7

2013-07-14 Thread Russell Keith-Magee 
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

2013-07-14 Thread Michael Manfre 
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

2013-07-14 Thread Russell Keith-Magee 
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

2013-07-14 Thread Curtis Maloney 
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

2013-07-14 Thread gilberto dos santos alves 
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

2013-07-14 Thread Ramiro Morales 
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

2013-07-14 Thread Russell Keith-Magee 
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

2013-07-14 Thread 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.

Spam on ticket #542

2013-07-14 Thread Aymeric Augustin 
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?

2013-07-14 Thread Jannis Leidel 

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?

2013-07-14 Thread Jannis Leidel 

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.