[django.contrib.postgres] Would this be accepted and how hard would it be to do?

[Some Developer]

Hi,

I'm a long term Django user but have never contributed to the main 
Django code base mainly because I haven't really needed any extra 
features. Until now.


I only use PostgreSQL as my database and the recent addition of 
django.contrib.postgresql got me thinking about other features of 
PostgreSQL that could be added to the Django code base that would be 
very useful for me and probably others.


Those features are PostgreSQLs built in support for the XML data type. 
These could be supported in Django with the addition of an XMLField. 
Because PostgreSQL supports querying the XML data directly some 
additions would have to be made to support these operations in the ORM 
(I think at least).


I've just checked out the latest Django source code and notice that 
there is a jsonb.py file in the django.contrib.postgres.fields package 
which I assume will support JSON in PostgreSQL in version 1.9. I'd like 
to do the same thing but with the XML data type.


Is this a project that a) would be accepted b) would be fairly straight 
forward and c) would be useful to the wider community? JSON is great and 
all but XML still has its uses in the world (I'm one of those people who 
prefer JSON but XML just offers more for the project that I am working on).


So thoughts?

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/558F4B7D.6070005%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unneeded index created with unique=True and db_index=False in TextField

[Some Developer]

On 15/04/15 23:45, Kevin Christopher Henry wrote:

This issue was the subject of https://code.djangoproject.com/ticket/24082.

There, the accepted (but not implemented) solution is the same as
suggested here: allowing the user to opt out of the creation of the
additional index with `db_index=False`.


Ah, sorry I didn't see that. That solution would certainly work.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/552EED1D.3060106%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unneeded index created with unique=True and db_index=False in TextField

[Some Developer]

On 15/04/15 18:22, Tim Graham wrote:

#19441 is the ticket where it was decided that unique=True implies a
database index. The documentation says,

"Note that when ``unique`` is ``True``, you don't need to specify

`Field.db_index`, because ``unique`` implies the creation of an index."



Understood. I just want to be able to stop the creation of the index in 
some way. Whether that be via db_index=False or some other new method.


I would have thought that the creation of the index would be optional. I 
understand that the default it to create the index and that is fine for 
the vast majority of cases (in fact until I hit this little problem I 
didn't care one way or another) but a user should have the option to 
tell Django not to create the index if they are sure they know what they 
are doing.



Unless we decide that is wrong, I think the correct condition to solve
the issue would be more like `field.db_index orfield.unique and
field.db_index is not False`. We might also have to change the default
keyword of Field from False to None so we know the difference between
"unspecified" and False.



--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/552EA9BD.1030001%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unneeded index created with unique=True and db_index=False in TextField

[Some Developer]

On 15/04/15 03:37, Curtis Maloney wrote:

Was the OP referring to the unique index, or the index created for the
LIKE lookups?

I was involved in a discussion recently [was there something on list
too?] wanting to be able to opt-out of the second index because they
knew they didn't need it, and it was _huge_ on their database.

--
C



The index created for the LIKE lookups.

The index name even has _like appended on to the name so I'm pretty sure 
that this is the problem at hand.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/552E944D.7050500%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Unneeded index created with unique=True and db_index=False in TextField

[Some Developer]

Using Django 1.8, psycopg2 2.6 and PostgreSQL 9.4.1.

I have a model with a models.TextField(unique=True, db_index=False, 
primary_key=False) field in it.


I understand that an index is created because of the comment shown in 
this code:


https://github.com/django/django/blob/master/django/db/backends/postgresql_psycopg2/schema.py#L17

but even though the index is suggested for LIKE queries using non C 
locales I would have thought the addition of db_index=False would have 
negated that.


I feel that this is a bug. An index is not required by PostgreSQL on a 
unique constraint (it may be recommended but that is beside the point) 
and if I explicitly state db_index=False then the Django ORM should 
remove the index even though the index is recommended.


Thoughts?

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/552DB881.1090006%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django documentation doesn't show correctly in any browser

[Some Developer]

On 14/01/15 01:06, Jannis Leidel wrote:



On 14 Jan 2015, at 01:24, Some Developer <someukdevelo...@gmail.com> wrote:

On 13/01/15 19:48, patrick91 wrote:


I cannot see any of these on my mac, I'll see if I have any linux
machine where I can see if I can reproduce.

Meanwhile, can you tell us if you have the same styles for the code
tags? https://up.kibakoapp.com/AaFwwhccdE
Also try to play with font-family. Maybe it is a font issue, even if you
have disabled webfonts, there can be something wrong with fonts in your
system.



If I manually delete the "Fira Mono" font from the font-family using the Google 
Chrome dev tools then the page works as expected. So yeah seems to be a web font issue.


Sigh, yeah, the package probably ships with an old version of the font that is 
somehow corrupted and is still favored by the browser. FWIW others have had the 
same problems: 
https://github.com/rust-lang/rust/issues/19257#issuecomment-66950412

The underlying problem is that we use Google's web fonts hosting for serving 
the Fira Mono font that has a local() statement for both styles 
(http://fonts.googleapis.com/css?family=Fira+Mono:400,700) which means it'll 
try the local version first, which kinda defeats the purpose with Fira Mono 
anyways, unless you're running Firefox OS for some reason :)

The font has also received quite a few updates since it was added to Google's 
hosting service, so I just deployed our own version to the site and hope that 
fixes your issue. Can you double-check if it works now?

Jannis



Working fine now. Thanks!

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54B5C25E.2030304%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django documentation doesn't show correctly in any browser

[Some Developer]

On 13/01/15 19:48, patrick91 wrote:


I cannot see any of these on my mac, I'll see if I have any linux
machine where I can see if I can reproduce.

Meanwhile, can you tell us if you have the same styles for the code
tags? https://up.kibakoapp.com/AaFwwhccdE
Also try to play with font-family. Maybe it is a font issue, even if you
have disabled webfonts, there can be something wrong with fonts in your
system.



If I manually delete the "Fira Mono" font from the font-family using the 
Google Chrome dev tools then the page works as expected. So yeah seems 
to be a web font issue.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54B5B743.60801%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django documentation doesn't show correctly in any browser

[Some Developer]

On 13/01/15 20:11, Raphael Michel wrote:

Am Tue, 13 Jan 2015 20:36:45 +0100
schrieb Aymeric Augustin :

Well, there are 10k subscribers to this list. Who else is seing this?


I don't, and I run pretty much the same configuration (Chrome on Arch
Linux on multiple computers). I think it pretty obviously is an issue
with the Fira Mono webfont, so maybe some weird font cache
configuration issues. Does this web page work for you?
https://mozilla.github.io/Fira/

Best regards,
Raphael



Some of it works and some of it doesn't.

One of the sections in the Light category doesn't show anything. Nothing 
in Medium, Bold or Regular works.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54B5B664.3000208%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django documentation doesn't show correctly in any browser

[Some Developer]

On 13/01/15 23:10, Jannis Leidel wrote:


I just deployed a potential fix, can you try again?

Jannis



Same issue I'm afraid.

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54B5B5E0.6050207%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Django documentation doesn't show correctly in any browser

[Some Developer]

I know this isn't strictly speaking a Django dev topic but since the 
developers are the ones who changed the Django documentation theme / 
appearance they should probably be made aware of the problem.


http://imgur.com/FtEpcdy
http://imgur.com/1ON8xxs
http://imgur.com/C6G0DfI

Above are some screenshots of what I see when I go to visit the Django 
documentation. This happens on all browsers I have available (latest 
Google Chrome, latest Firefox and Opera beta). I'm running on Arch Linux 
and up until the recent documentation change I have never had a problem 
with the Django docs or any other website for that matter.


I've checked the Google dev console and Firebug for information but 
there are no errors, I completely cleared the cache and restarted the 
browser which didn't help. I've completely disabled web fonts in Firefox 
still no luck at all. Something must have been done in the recent 
documentation overhaul which has broken something somewhere (have to 
admit to being somewhat annoyed at the change - if it ain't broke don't 
fix it).


As far as things stand at the moment the Django documentation is 
completely and utterly unusable.


Any suggestions? I'm pretty sure I can't be the only one who is having 
issues.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54B56EC5.7060500%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Supported Python versions in future Django versions

[Some Developer]

On 15/11/14 15:33, Aymeric Augustin wrote:

Hello,

The Django team has been discussing the timeline for dropping
support for older Python versions. The current consensus is:

- Support Python 2.x until the LTS version after 1.8, which should
   be released late 2017 or early 2018 and supported until 2020,
   when official support for Python 2.x ends.

- Drop support for Python 3.2 in Django 1.9 because its market
   share isn’t significant nor going to increase.



Interesting.

Are there any stats available for market share of the various versions 
of Python 3? If Python 3.3 has a similarly small market share you could 
drop that as well and start with Python 3.4 which is the first version 
of Python 3 I have felt was good enough to use for actual projects 
rather than just tinkering around.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/546B2524.40604%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: deprecating ipaddressfield (at some time)

[Some Developer]

On 25/08/2013 11:25, Aymeric Augustin wrote:

On 18 mai 2013, at 14:07, Erik Romijn  wrote:


As far as I know, IPAddressField has no current features that are not also 
available in a GenericIPAddressField. Therefore, I suggest that we, some time 
from now, deprecate IPAddressField, in favour of GenericIPAddressField.


Yes. Having both only creates confusion for users of Django.



I agree. I don't see any need at all to keep both around. IPv4 addresses 
have already been depleted in two areas and the US is due to follow 
shortly. Soon it will be IPv6 or nothing for new ventures unless they 
can get hold of their IPv4 addresses from someone else.


--
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: Usage and documentation of F()

[Some Developer]

On 14/08/13 10:05, Marc Tamlyn wrote:

(Disclaimer: I didn't write any of this code, I'm just working from my
own possibly flawed understanding)

The main point of using F is not generally for performance per se,
rather for database consistency. In the first example, the performance
increase is negligable, but you get two significant benefits. The first
is that you minimise the risk of race conditions by effectively issuing
"increment" rather than "set" to the database. The second is that you
can increase a number of rows the same way -
Product.objects.update(number_sold=F('number_sold') + 1). These add
performance in that you end up doing fewer queries, but that's actually
what you're gaining.

It is worth noting that the *only* reason to set an attribute to be an F
expression is to then update the value in the database. In fact, you
cannot access the value after you've done this, you get a
"django.db.models.expressions.ExpressionNode" instance. In that sense,
doing product.number_sold = F('number_sold') + 1 is really a long hand
version of the update() query.

As for what expressions are valid, I believe the things you suggested do
work, but I imagine exactly what works will depend on what operations
the database (and backend) support. Django itself isn't doing anything
clever here, it's just providing some architecture to allow you to
delegate functionality to the database.

I agree that the main documentation for F() should reference the update
case (IMO as an update() rather than the longhand version).

Marc


On 13 August 2013 20:22, Daniele Procida > wrote:

I noticed while looking for material for
 that


mentions that:

 product.number_sold = F('number_sold') + 1

is faster than:

 product.number_sold += 1

though this doesn't seem to be mentioned in the database
optimisation page.

That's easy enough to address, and


seems like a sensible place for it.

However the mentions of F() that I did find raised a number of
questions.

The F() class seems to be a handy general-purpose way to refer to
the value of a model field..


Firstly, it's not explained how, in expressions like:

 product.number_sold = F('number_sold') + 1

(from

)
Django knows that F('number_sold') is refers to the product model.

Does it know because product.number_sold is the field that this
expression refers to? What would happen if we did:

 product.number_in_stock = F('number_in_stock') - F('number_sold)

(i.e. can we make such calculations multiple other fields in one
go?), or:

 product.number_to_reorder = F('number_sold)

for example? What are the rules of the usage syntax of F()?

Secondly, the main documentation for F()


doesn't mention this kind of use at all: it only suggests that it
might be useful in queries.

Since this use seems to be just one of multiple uses for F(),
shouldn't a more general description of F() belong somewhere else
(where) instead?


Finally, are there any other useful ways to use F() not covered by
these two examples?


Daniele


I've always found the documentation on the usage of F() to be somewhat 
substandard compared to the rest of the documentation to the point were 
I rarely if ever use it.


If the documentation could be beefed up I'm sure more people would be 
happy to use it in the general case rather than just small side cases.


--
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

[Some Developer]

On 23/07/13 02:07, Curtis Maloney wrote:

Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]

So, if you feel like helping out with django-fastcgi ... I'm happy for
the help :)

--
Curtis


Fork it and upload it to Github and then we can see where we stand. 
Github probably has the best chance of getting people involved with it.


But yeah I'm available to help. Although I'm back at work next week so 
my time will be somewhat more limited than it is at the moment.


--
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

[Some Developer]

On 22/07/13 10:00, Russell Keith-Magee wrote:

The hope is to start accelerating the release cycle slightly; however,
this also depends on someone actually doing the work :-)


Sounds good. I'd love to start helping with Django myself but I feel a 
bit lost when it comes to useful things to do. Maybe I'll start checking 
out the bug tracker and seeing what I can do there.


--
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

[Some Developer]

On 22/07/13 05:47, Russell Keith-Magee wrote:

Based on the feedback from this thread (and the fact that multiple core
devs, including a BDFL have weighed in), I think it's safe to say that
the decision has been made. The only question at this point is how long
it takes before someone commits the changeset that implements the start
of the deprecation process.

Yours,
Russ Magee %-)


Thanks. Its always better to know that a definitive decision has been made.

I guess now we can start looking into third party alternatives.

To anyone else reading this thread who is still wanting FastCGI I am 
willing to help with a third party solution if something is going to 
come together. Based on the normal Django release cycle I'd expect 1.7 
to be out in either Q4 this year or Q1 next year so something needs to 
be done by then (preferably including testing in production - something 
which I can help with).


P.S What's a BDFL? :)

--
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

[Some Developer]

On 14/07/13 20:17, Florian Apolloner wrote:

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


So has this decision been made yet? If it has myself and others can 
start coming up with solutions for those who want FastCGI. If it hasen't 
then we can avoid wasting time on something that is going to be a non-issue.


The sooner that work is started before 1.7 though means that it might 
not actually be a problem for users since FastCGI will still work.


--
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

[Some Developer]

On 21/07/2013 05:08, Curtis Maloney wrote:

I wasn't aware there was a particular performance issue, but I'll
certainly keep it in mind.


Take a look at this:

http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi

I've probably already said it but if you want some help with this 
project I'd be interested.


--
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

[Some Developer]

On 20/07/13 13:24, Christian Schmitt wrote:

No FastCGI isn't a bad protocol. But it's not recommand to deploy Python
Application's with FastCGI. FastCGI is good for deploying PHP or even
sometimes Golang (but here, the plain Webserver is better).
But! FastCGI is a low level protocol and WSGI tries to get rid of that.
Flup is just a server/middleware that makes a WSGI based Application to
a SCGI/FCGI one. It's never recommand to use a low level api, when you
don't have to.
Also people who deployed on FastCGI should change that behavior to
mod_wsgi, and there are a shitload of hosters that already supporting
mod_wsgi, so it's really not that easy to change your hoster.

Btw. the djangoproject also have a good list which lists some hosters:
https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts


I think you have completely missed my point. The people I am talking 
about are the ones who maintain their own servers. Plus there are lots 
of languages out there than can be deployed using FastCGI (off the top 
of my head I know people use FastCGI for Haskell, Scheme, PHP, Go, Rust, 
Python, Perl, C, and C++).


Your argument about FastCGI being a low level protocol is a bit weak to 
be honest. Those using it know about the protocol and know how to work 
with it. mod_wsgi does not solve the problem I laid out in my previous 
post which is that it is better to have one deployment technology in use 
regardless of the language used. This is what makes FastCGI unique at 
the moment.


I'm longing for the day when uwsgi reaches the same level of adoption 
but it won't be for sometime yet.


--
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

[Some Developer]

On 20/07/13 12:32, Christian Schmitt wrote:

I would recommand to remove FastCGI.
That's the thing i love with the Python Community. Remove depracted or
obsolete things.

The thing is, there are way more important things to do, than supporting
a 'depracted' way to deploy. And it's really not that hard to get
mod_wsgi with a httpd running.
You could strip that down so easily and compile it, even on CentOS.


The thing that people seem to be missing here is that FastCGI is not 
obsolete. There is currently no other deployment technology that can 
reasonably replace it for the people who make use of it (with the 
possible exception of SCGI).


FastCGI is essential in environments where websites are hosted that use 
different languages and frameworks. WSGI is Python only and therefore 
would require two deployment methods based on technology used increasing 
maintenance overhead and ultimately cost.


uWSGI is starting to get a few more plugins written for it for other 
languages but it is still lacking somewhat (and when I have a couple of 
days spare I may well work on adding some of what I need).


Nor is FastCGI obsolete. People in the technology field suffer from a 
problem were old = bad when in fact old means stability which is crucial 
for important production sites. Flup may well have issues and I would be 
more than happy to work on fixing those issues but lets not mistake 
problems with Flup as problems with FastCGI itself. Flup is an 
implementation. FastCGI is a protocol and the protocol is just fine.



--
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

[Some Developer]

On 19/07/13 01:31, Curtis Maloney wrote:

For those who are keen to keep support for FastCGI, would you be
interested in helping me develop/maintain a Pure Python
FastCGI->WSGI(Django-specific) publisher package?

I agree it's valuable to have, as many have said [and I believe all have
agreed] but to keep it in core is unmaintainable.

And by "help", it could just be as much as feature requests,
documentation, or testing [always testing! :)]

--
Curtis Maloney


Post a link to a Github repo for the project and I'll watch it. I'm not 
sure how much time I'd be able to contribute to it but I'll certainly 
help where I can.


--
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

[Some Developer]

On 15/07/2013 13:37, Florian Apolloner wrote:

On Monday, July 15, 2013 9:38:33 AM UTC+2, Some Developer wrote:

This would be a mistake in my opinion.


Based on what? Django would still support FCGI via flup like it does
now, we'd just get rid of the management commands you usually can't use
on shared hosting either way…


OK. Your initial post was somewhat confusing in that case.


I'd like to get rid of everything FCGI-specific in Django sooner or later 
(rather sooner).


The question is why? There is very little FastCGI boilerplate in Django 
as it is and what is there hasn't been touched for a number of years 
(the runfcgi management command file hasn't been touched for 6 years).


Why not just remove the documentation for FastCGI, SCGI and AJP and make 
it clear that WSGI is the only supported option for deploying Django 
applications but keep the legacy code available for those who already 
use it.


Developers then don't need to worry about breaking it since it is no 
longer supported and those that do use FastCGI, SCGI and AJP can submit 
patches to fix it if it ever does get broken. This also includes 
submitting patches to flup if it is still maintained or taking it over 
if it is not.


This way everyone wins.

--
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

[Some Developer]

On 15/07/13 16:10, Florian Apolloner wrote:

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:

If you're suggesting to move the FastCGI code into a separate app: +1


I'd have just dropped it, but yes we can move it out; although someone
else will have to step up to continue maintaining it (if there is a need
to maintain it).

Florian


What about SCGI and AJP support? Is that going?

Seems silly to drop FastCGI which is probably the most popular of three 
and leave the other two intact. If you're going to drop something drop 
all three.


At least then it is clear to users that WSGI is the only supported 
option in Django.


Third parties can then maintain FastCGI, SCGI and AJP support (which I 
believe all come from flup anayway).


--
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

[Some Developer]

On 15/07/13 13:13, mjl Martin J. Laubach wrote:

   Is there actually a problem with flup? Not being maintained doesn't
mean it's totally broken and it obviously works just fine for a lot of
folks?

 mjl


I use it myself and haven't had any issues with it either I was just 
responding to one of the previous posters who stated that because flup 
was unmaintained it was a good reason to deprecate FastCGI in Django. He 
did make a good point about there being no bug tracker but as I said if 
it became a critical issue then a fork is always on the cards.


I'd be interested if any contact has been made with the author of flup 
to see whether he has dropped the project or whether he just doesn't get 
any bug reports warranting a new release.


Personally I haven't had any issues with flup at all. In fact for me 
Django with flup + nginx + daemontools works wonderfully for production 
sites. Perhaps not as fast as uWSGI but it is solid enough.


--
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.