Re: uWSGI documentation
Il giorno 02/apr/2011, alle ore 16.44, Łukasz Rekucki ha scritto: > On 2 April 2011 13:23, James Pic wrote: >> Hello everybody, >> >> Do you think uWSGI deserves a place in the official django documentation ? >> >> I think it should because it's easier, safer, faster and more secure >> than flup or mod_wsgi. Also, it made my sysadmin life really easy and >> that's something cool to share with the community. >> >> In this case, please consider the attached draft >> (django/docs/howto/deployment/uwsgi.txt): it's not perfect and >> probably not commitable as-is, but I am ready to listen to feedback >> and improve it. Otherwise it'll just make another blog post. > > +1. More docs didn't hurt anybody. At least while there is someone to > maintain them. > >> >> What do you think ? >> > > My first impression is that you're focusing too much on all those > switches. That section got me totally lost. That should be simplified. > Also, do I really need to type all that stuff? I probably won't be > doing that on production, so showing how to place it in a > configuration file would be better. > > I would also drop the whole "advantages" section. The purpose of the > page is to show how to deploy a Django app on uWSGI, not compare it > against other solutions. You also mention some features, but never > show how to enable/use them which is confusing. > > PS. Do you think having a `runuwsgi` command similar to `runfcgi` > would be useful ? > > I have made a tiny runuwsgi implementation: http://projects.unbit.it/uwsgi/browser/contrib/runuwsgi.py it tries to autoload plugins and spawn the embedded http router/proxy on a default port. You can specify the socket=ADDR option to disable the http part and bind the server on a uwsgi socket (for directly pointing your webserver to it) It run multithreaded (8 threads) but i suppose that this could be another configurable option. It requires a 0.9.7.2 uWSGI version (released in a couple of days) or the current mercurial tip. I hope it can be useful -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC] Composite fields
On Sun, Apr 03, 2011 at 02:52:01PM -0400, Carl Meyer wrote: > I haven't had time yet to sit down and look at your implementation > questions for a CompositeField (how it works with lookups and Qs, etc), > but I do think that one design goal for a CompositeField implementation > is that we should be able to reimplement the Generic Foreign Key as a > CompositeField. I think your proposal could get there fairly easily -- > all that's needed is for the mapping to and from the Python > representation to be customizable by a CompositeField subclass. So a > namedtuple representation is a sane default, but a GFK implementation > could override that to map to and from actual model objects instead. The design idea looks good to me. Maybe this could even be done in such a fashion that the following things would work: >>> TaggedItem.objects.filter(content_object=guido) >>> TaggedItem.objects.get(content_object=guido) I'll definitely give it some thought. As I understand it, the problem with these constructs is that the Q object that would be created isn't capable of comparing two actual fields at once and this is exactly what I'm trying to figure out how to do with CompositeFields. Michal Petrucha signature.asc Description: Digital signature
Re: uWSGI documentation
On Apr 2, 1:23 pm, James Pic wrote: > I think it should because it's easier, safer, faster and more secure > than flup or mod_wsgi. Also, it made my sysadmin life really easy and > that's something cool to share with the community. +1 on more docs, since uwsgi is quite useable by now. But please leave claims like faster etc out if you can't back it up. Especially since david cramer showed on pycon that it makes no difference for them and both are equal... (and yes I do consider disqus as a relevant benchmar ;)) Cheers, florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
Hi, How uwsgi is more secure than FastCGI ? I believe that running manage.py for production deployments is "not way to go", as it has been noted by django devs previously. What purpose would runuwsgi command serve ? On Sat, Apr 2, 2011 at 2:23 PM, James Pic wrote: > Hello everybody, > > Do you think uWSGI deserves a place in the official django documentation ? > > I think it should because it's easier, safer, faster and more secure > than flup or mod_wsgi. Also, it made my sysadmin life really easy and > that's something cool to share with the community. > > In this case, please consider the attached draft > (django/docs/howto/deployment/uwsgi.txt): it's not perfect and > probably not commitable as-is, but I am ready to listen to feedback > and improve it. Otherwise it'll just make another blog post. > > What do you think ? > > Cheers > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> Hi, > How uwsgi is more secure than FastCGI ? I think he is referring to the various included jailing systems (chroot, linux namespaces, posix capabilities...) because if we are talking about protocols there are no really differences between uwsgi and FastCGI, both are unsecure by-design :) > I believe that running manage.py for production deployments is "not > way to go", as it has been noted by django devs previously. > What purpose would runuwsgi command serve ? I see it as a way to easily use the embedded uwsgi module/api before going into production. If a user want to use something like the uWSGI timer/cron system http://projects.unbit.it/uwsgi/wiki/DjangoTimers http://projects.unbit.it/uwsgi/wiki/CronInterface it can just start coding without passing for all the stack configuration. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC] Revised form rendering
2011/4/4 Daniel Greenfeld :
> Anyway, as the current lead on Django Uni-Form I think its great that Gregor
> is picking up the torch for refactoring form rendering in Django 1.40. He's
> obviously done his homework and put a lot of thought into this critical part
> of Django.
> I'm not a core developer my vote doesn't count, but I'm giving it anyway. +1
> from me.
> Daniel Greenfeld
Hi Daniel, I really appreciate your support. It shows that I might be on the
right path for a successfull refactoring. Thanks.
@all:
I've updated my proposal. Mainly the media tag part and the timeline estimates
(nothing really exciting for the moment). A revision of the chrome section
will follow tomorrow. Have a look at the proposal online [1] or look below,
I've included the changed bits:
GSoC 2011 Proposal - Revised form rendering
...
Media aka. JS/CSS
-
One of the other mainpoints in the discussions I reviewed for this proposal was
the use of JS and CSS files that must be maintained somehow to display them
how we already do through the media framework (e.g. ``{{ form.media }}``).
The problem with this is that with the new template tag we can change some
of the widgets in the template and introducing new dependencies. Thats why I
would like to have an alternative for the ``using`` argument in the
``{% form %}`` tag.
If ``using`` is replaced with ``configure``, the ``{% form %}`` tag will _not_
output the HTML in the current place. However it will record and remember the
usage of widgets and fields to determine which media files are required. An
example template would look like::
{% block extrahead %}
{% form myform configure widget "CalendarInput" for myform.birthday %}
^--- The new widget for the field birthday will be
recorded, but the form will not be rendered.
{{ myform.media.css }}
^--- Outputting all necessary css files.
{% endblock %}
{% block content %}
{% form myform %}
^--- The form will be rendered as usual but with the
"CalendarInput" widget that was specified in the other tag.
{% endblock %}
{% block footer %}
{{ myform.media.js }}
^--- Outputting all necessary js files at the end of the document.
{% endblock %}
I will also check the possibility and difficulty of a new ``{% formmedia %}``
tag that hooks into the template parsing system, reading until the end of the
template and analyzing the use of the ``{% form %}`` tag. This way it could
determine all changes that will be applied to the form before it gets
rendered, including all the necessary CSS dependencies that needs to be
imported in the header of the page.
It is not clarified yet, if the ``{% formmedia %}`` is possible at all with
the current template parsing implementation. There might be some risks that
need to be sorted out before starting with the implementation:
* By parsing from the ``{% formmedia %}`` tag until the end of the template
might result in that all content after this tag is represented as a child
node of it. What side effects are implied? Does it produce backwards
incompatibilities with thirdparty template tags?
* What happens if the ``{% form %}`` tag is changing the widget of the form
based on a context variable?
Estimates
-
...
1st week: Starting to layout the documentation. The form tag syntax based on
discussions from the mailing list should already be finalized.
2nd week: Examing what unittests are available for the current form rendering
and making sure they are stable for testing backwards compatibility during the
project.
3rd week: I will attend DjangoCon EU, hopefully giving a talk about the
revised form rendering and collecting more feedback in an open space.
4th week: Converting the current layouts into template based renderers, ensuring
backwards compatibility.
Goal: no HTML should be left now in the python source.
5th week: Mainly working on documentation and integrating the very last changes
based on discussions from DjangoCon EU.
Goal: All public APIs should be stable.
6th week: Starting to write tests and implementing the ``{% form %}`` tag to
be able to emulate all the rendering that is currently possible.
7th week: Implementing the necessary rendering modifiers like "fields",
"layout" etc. and the API for chrome.
8th week: Implementing the ``{% formmedia %}`` tag.
Goal: Project should be feature complete.
9th - 11th week:
* Validating backwards compatibility for the ``{% formmedia %}`` parsing
implementation with thirdparty modules (see Media section).
* Converting the admin to use the new form rendering.
* Integrating lessons learned from the admin.
* Bugfixes and regression tests for problems that showed up in the work with
the admin.
Goal: Code should be ready to be used in sample projects.
12th week: Finalizing, bugfixes and tweaking the document
Re: Bug when generating sql for single (AND: (EverythingNode))
Omg, I've just reviewed this bug, it's still there but this message is completely confusing. A little correction: On 25 Lut, 14:14, trybik wrote: > Hi, > > when generating sql forWhereNoderepresented as (AND: > (EverythingNode)), > inhttp://code.djangoproject.com/browser/django/trunk/django/db/models/s... > the empty variable will stay False, True of course (L88), not False... the point is that L105 will never be reached because of treacherous 'continue' in L113. > thus throwing the EmptyResultSet > further on (L120) and in consequence e.g. returning EmptyQuerySet on > higher level. Imvho, in case of FullResultSet handling you're missing > setting empty variable to True and here False, not True (between L104 and L105); removing L113 would also do the trick in this case. Best regards, Mikołaj > (can be first thing done after catching the exception). > > How one can get (AND: (EverythingNode))WhereNodeto be > generated?http://code.djangoproject.com/browser/django/trunk/django/db/models/s... > > Best regards, > Miko³aj -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bug when generating sql for single (AND: (EverythingNode))
Hi Mikołaj, On 4 April 2011 19:46, trybik wrote: > Omg, I've just reviewed this bug, it's still there but this message is > completely confusing. A little correction: It's best to report bugs on the tracker. Otherwise, they'll die in infinite depths of everyone's mailboxes. > > On 25 Lut, 14:14, trybik wrote: >> Hi, >> >> when generating sql forWhereNoderepresented as (AND: >> (EverythingNode)), >> inhttp://code.djangoproject.com/browser/django/trunk/django/db/models/s... >> the empty variable will stay False, > > True of course (L88), not False... the point is that L105 will never > be reached because of treacherous 'continue' in L113. > >> thus throwing the EmptyResultSet >> further on (L120) and in consequence e.g. returning EmptyQuerySet on >> higher level. Imvho, in case of FullResultSet handling you're missing >> setting empty variable to True > > and here False, not True (between L104 and L105); removing L113 would > also do the trick in this case. It's still not very clear to me what problem are you describing. If you could produce a queryset that generates wrong SQL, it would clearify things. >> How one can get (AND: (EverythingNode))WhereNodeto be >> generated?http://code.djangoproject.com/browser/django/trunk/django/db/models/s... Good question. You can see it's generated in combine()[1], but I'm not sure how you can make a Query object with "self.where" attribute that would evaluate to False. [1]: http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/query.py#L478 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC] Composite fields
On Sun, Apr 03, 2011 at 03:08:51PM -0400, Alex Gaynor wrote: > Like Carl I haven't had time to properly read this, but one important thing > (IMO) to think about is not just having composite field support, but support > for "virtual" fields in general, that is fields that don't map to a database > column. This is for things like serialization, querying, forms, etc. (you > know all the places we use metadata). Now I'm not sure I understand what exactly you have in mind. Just being able to have them in models and not breaking the things you mentioned or adding some special support? As for serialization, currently I don't see any mechanism that could tell the serializers to skip certain fields. This would probably be required to handle them cleanly. Of course, this could be hacked around by returning something like None or an empty string from value_to_string and ignoring the value in raw saves, but a mechanism in the serializers would be nicer, I think. As for querying, I think I already found out how to implement this. I'll post a reply to my original mail since I find it more appropriate to answer the question I asked there. (I hope I'm not creating too much noise here. (-: ) About forms, explicit virtual fields should be ignored altogether by default except for ForeignKeys (generic and regular ones) which should behave, well, as GFKs and regular ForeignKeys as they do now. This is where the same encoding as proposed for admin URLs could be used to pass the actual value. Nevertheless, I'm not sure what you mean by "all the places we use metadata". Having taken a quick look at the documentation index, I don't see any relevant topic I haven't mentioned in previous e-mails, however, that doesn't mean I haven't overlooked something. Michal Petrucha signature.asc Description: Digital signature
Fixing makemessages for Javascript
Last week I re-encountered the problems with using makemessages on
Javascript files, and lost a couple of half-days to trying to figure out
why some of my translatable messages weren't being found and deposited
into my .po files. After fully understanding the extent of Django's
current hack, I decided to take a stab at providing a better solution.
Background: today, Javascript source files are parsed for messages by
running a "pythonize" regex over them, and giving the resulting text to
xgettext, claiming it is Perl. The pythonize regex simply changes any
//-style comment on its own line into a #-style comment. This strange
accommodation leaves a great deal of valid Javascript syntax in place to
confuse the Perl parser in xgettext. As a result, seemingly innocuous
Javascript will result in lost messages:
gettext("xyzzy 1");
var x = y;
gettext("xyzzy 2");
var x = z;
gettext("xyzzy 3");
In this sample, messages 1 and 3 are found, and message 2 is not,
because y;ABC;abc; is valid Perl for a transliteration operator.
Digging into this, every time I thought I finally understood the full
complexity of the brokenness, another case would pop up that didn't make
sense. The full horror of Perl syntax
(http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators ,
for example) means that it is very difficult to treat non-Perl code as
Perl and expect everything to be OK. This is polyglot programming at
its worst.
This needs to be fixed. To that end, I've written a Javascript lexer
(https://bitbucket.org/ned/jslex) with the goal of using it to
pre-process Javascript into a form more suitable for xgettext. My
understanding of why we claim Javascript is Perl is that Perl has regex
literals like Javascript does, and so xgettext stands the best chance of
parsing Javascript as Perl. Clearly that's not working well. My
solution would instead remove the regex literals from the Javascript,
and then have xgettext treat it as C.
I have a few questions you can help me with:
1. Is this the best path forward? Ideally xgettext would support
Javascript directly. There's code out there to add Javascript to
xgettext, but I don't know what shape that code is in, or if it's
reasonable to expect Django installations to use bleeding-edge
xgettext. Is there some better solution that someone is pursuing?
2. Is there some other badness that will bite us if we tell xgettext
that the modified Javascript is C? With a full Javascript lexer, I feel
pretty confident that we could solve issues if they do come up, but I'd
like to know now what they are.
3. I know that lexing Javascript is tricky. I need help finding
diabolical test cases for my lexer (https://bitbucket.org/ned/jslex).
Anyone care to come up with some Javascript source that it can't
properly find the regex literals in?
BTW: This would close tickets #7704, #14045, #15331, and #15495.
--Ned.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 4 April 2011 23:15, Ned Batchelder wrote: > > I have a few questions you can help me with: > > 1. Is this the best path forward? Ideally xgettext would support Javascript > directly. There's code out there to add Javascript to xgettext, but I don't > know what shape that code is in, or if it's reasonable to expect Django > installations to use bleeding-edge xgettext. Is there some better solution > that someone is pursuing? It would be best to have xgettext allow pluggable parsers or/and rewritten in Python. Oh wait, it's called Babel ;). I was planning to refactor the `makemessages` command to enable custom parsers (My motivation is having a bunch of client-side templates written in a variant of Mustache or jQuery Templates). As babel already has an interface for that, integrating it into Django would be cool. Sure, it's a dependancy, but so is xgettext. > > 2. Is there some other badness that will bite us if we tell xgettext that > the modified Javascript is C? With a full Javascript lexer, I feel pretty > confident that we could solve issues if they do come up, but I'd like to > know now what they are. IMHO, it would be best to leave only gettext() calls and pad them with comments, so that line numbers match (the template converter does something similar, by replacing all other stuff with string like ). You can then choose C, Python or whatever :) > > 3. I know that lexing Javascript is tricky. I need help finding diabolical > test cases for my lexer (https://bitbucket.org/ned/jslex). Anyone care to > come up with some Javascript source that it can't properly find the regex > literals in? I'll give it a spin on my code :) Thanks for doing this! -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 4/4/2011 5:45 PM, Łukasz Rekucki wrote: On 4 April 2011 23:15, Ned Batchelder wrote: I have a few questions you can help me with: 1. Is this the best path forward? Ideally xgettext would support Javascript directly. There's code out there to add Javascript to xgettext, but I don't know what shape that code is in, or if it's reasonable to expect Django installations to use bleeding-edge xgettext. Is there some better solution that someone is pursuing? It would be best to have xgettext allow pluggable parsers or/and rewritten in Python. Oh wait, it's called Babel ;). I was planning to refactor the `makemessages` command to enable custom parsers (My motivation is having a bunch of client-side templates written in a variant of Mustache or jQuery Templates). As babel already has an interface for that, integrating it into Django would be cool. Sure, it's a dependancy, but so is xgettext. I don't understand yet how Babel fits into the ecosystem, but if it's a better xgettext, then that might be the way to go. I see a jslexer.py in the source, I wish I'd seen that a few days ago! :) 2. Is there some other badness that will bite us if we tell xgettext that the modified Javascript is C? With a full Javascript lexer, I feel pretty confident that we could solve issues if they do come up, but I'd like to know now what they are. IMHO, it would be best to leave only gettext() calls and pad them with comments, so that line numbers match (the template converter does something similar, by replacing all other stuff with string like ). You can then choose C, Python or whatever :) I saw your comment to that effect on one of the tickets. That approach would probably also work. All of these approaches presuppose accurate tokenization of the Javascript, which we can now do. --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 04.04.2011, at 23:15, Ned Batchelder wrote:
> Last week I re-encountered the problems with using makemessages on Javascript
> files, and lost a couple of half-days to trying to figure out why some of my
> translatable messages weren't being found and deposited into my .po files.
> After fully understanding the extent of Django's current hack, I decided to
> take a stab at providing a better solution.
>
> Background: today, Javascript source files are parsed for messages by running
> a "pythonize" regex over them, and giving the resulting text to xgettext,
> claiming it is Perl. The pythonize regex simply changes any //-style comment
> on its own line into a #-style comment. This strange accommodation leaves a
> great deal of valid Javascript syntax in place to confuse the Perl parser in
> xgettext. As a result, seemingly innocuous Javascript will result in lost
> messages:
> gettext("xyzzy 1");
> var x = y;
> gettext("xyzzy 2");
> var x = z;
> gettext("xyzzy 3");
> In this sample, messages 1 and 3 are found, and message 2 is not, because
> y;ABC;abc; is valid Perl for a transliteration operator. Digging into
> this, every time I thought I finally understood the full complexity of the
> brokenness, another case would pop up that didn't make sense. The full
> horror of Perl syntax
> (http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators , for
> example) means that it is very difficult to treat non-Perl code as Perl and
> expect everything to be OK. This is polyglot programming at its worst.
>
> This needs to be fixed. To that end, I've written a Javascript lexer
> (https://bitbucket.org/ned/jslex) with the goal of using it to pre-process
> Javascript into a form more suitable for xgettext. My understanding of why
> we claim Javascript is Perl is that Perl has regex literals like Javascript
> does, and so xgettext stands the best chance of parsing Javascript as Perl.
> Clearly that's not working well. My solution would instead remove the regex
> literals from the Javascript, and then have xgettext treat it as C.
Thanks Ned, I meant the post about this issue here after 1.3, since we also
talked about this during the Pycon sprint, especially since we seem to have hit
a few more problems with the recent gettext 0.18.1.1 (such as a seemingly
stricter Perl lexer) -- which I encountered while I applied the final
translation updates right before 1.3 but didn't have time to investigate yet.
The bottom line is that I think we should rethink the way we look for
translateable strings instead of working around the limitations of xgettext.
> 1. Is this the best path forward? Ideally xgettext would support Javascript
> directly. There's code out there to add Javascript to xgettext, but I
> don't know what shape that code is in, or if it's reasonable to expect Django
> installations to use bleeding-edge xgettext. Is there some better solution
> that someone is pursuing?
We can't really expect Django users to upgrade to the most recent (or even an
unreleased) version of gettext, We've bumped the minimum required version in
Django 1.2 to 0.15 once all OSes were covered with installers. Which made me
talk to Armin Ronacher about using Babel instead of GNU gettext, since it has a
JavaScript lexer and is in use in Sphinx and Trac. [1] In that sense, I
wholeheartedly encourage you to take a stab at it for 1.4 -- if you think
that's a good idea.
Having a Python based library (assuming it works similarly) seems like a better
fit to Django than relying on a C program.
> 2. Is there some other badness that will bite us if we tell xgettext that the
> modified Javascript is C? With a full Javascript lexer, I feel pretty
> confident that we could solve issues if they do come up, but I'd like to know
> now what they are.
I feel this is much better solved once and fall all than to keep misusing
xgettext.
Jannis
1: http://babel.edgewall.org/browser/trunk/babel/messages/jslexer.py
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
