Re: uWSGI documentation

[Graham Dumpleton]

To be blunt, you are actually asking a lot for them to host detailed 
documentation on uWSGI integration on the Django site for every possible way 
it can be setup. I haven't even managed to get much more than minimal setup 
instructions for mod_wsgi into the official Django documentation.

I believe you will find that they don't really believe it is for them to be 
providing extensive documentation on particular hosting mechanisms, or at 
least they don't have the time. Personally I do find that stance a bit odd 
as they should be striving to at least ensure that it is as painless as 
possible for users to get it going on at least the mainstream hosting 
methods to combat the accusations that it is too hard. As such, the minimal 
documentation they provide at the moment is quite often not enough.

To me this should extend to ensuring that interfaces in the framework make 
it easy and predictable. It is a said state of affairs though that pretty 
well all the Python web frameworks give minimal time to ensuring that the 
experience of a user as far as hosting it is as simple as possible and why 
every framework is so different and don't use some sort of common defining 
mechanism for an entry point.

I would thus perhaps suggest you instead provide just the most common 
configuration which will work for most users and would be easiest and then 
have a link back to any more detailed documentation on your own site 
relevant specifically to Django, as well as link to more general purpose 
documentation on your own site. It would then be the documentation on your 
site which describes all the variations.

If you really want to attract Django users, you might also consider what I 
have had on my TODO list for quite a while, but haven't had time to do (but 
might this year), which is to write a distinct comprehensive self contained 
tutorial on how to setup your WSGI hosting mechanism with Django. This can't 
though just concentrate on the specifics of your hosting mechanism, but 
because newbies are sometimes quite inexperienced, touch on issues of user 
rights, file system permissions, where stuff should be installed and general 
security concerns, plus how to manage updates of Django and application code 
etc etc. Yes, it is a lot of work, but if you really want to try and attract 
users of a specific framework to you, you need to do it eventually.

Graham

On Saturday, April 9, 2011 2:40:24 PM UTC+10, Roberto De Ioris wrote:
>
>
> > That said i'd love to *not* have to put a 3 liners module in my
> > project directory anymore. A runuwsgi command might not be the only
> > way to solve this need.
> >
>
>
> Remember that you do not need those file anymore:
>
> [uwsgi]
> env = DJANGO_SETTING_MODULE=mysite.settings
> chdir = 
> module = django.core.handlers.wsgi:WSGIHandler()
> ...
> ...
>
> Or you can do magic with placeholder like this:
>
> [uwsgi]
> my_django_app = mysite
> env = DJANGO_SETTING_MODULE=%(my_django_app).settings
> chdir = /apps/%(my_django_app)
> module = django.core.handlers.wsgi:WSGIHandler()
>
> (obviously this rules apply to xml,yaml,ldap,command line and so on...)
>
>
> > uWSGI_ supports configuration through:
> >
> > * command line switches
> > * ini files
> > * xml files
>
> yaml is supported too and you should mention environment variables, they 
> are
> used a lot on already available *BSD init scripts
>
> Probably i would add a section about massive hosting of applications using
> the Emperor (The Emperor doc is probably the only good one of all the
> uWSGI project as it is not written by me :) )
>
> http://projects.unbit.it/uwsgi/wiki/Emperor
>
> One of the most-loved (by me too) feature of mod_wsgi is its
> virtualhosting capability
> tied-in with apache. uWSGI in the past forced you to manually manage a
> instance for every app or use the PITA (but funny and hacky)
> multiple-interpreters-way. The Emperor solves this problem elegantly and
> with a lot of attention about clouding/hosting platforms.
>
> >
> > Starting the server
> > ---
> >
> > Starting an uWSGI_ server is the role of the system administrator,
> > like
> > starting the Web server. It is *not* the role of the Web server to
> > start the
> > uWSGI_ server. This means:
> >
> > * the uWSGI_ server can be restarted or reloaded independently from
> > the Web
> >   server,
> > * it is the role of the system administrator to make uWSGI_ to start
> > on boot
> >   or reboot: either through tools like supervisor or daemontools,
> > either
> >   directly at init level in a file like /etc/rc.local or /etc/conf.d/
> > local
>
>
> Nothing to say against this, but Cherokee (as an example) manages the
> uWSGI processes itself (it is an exception to the rule, i do not know if
> it is worth mentioning it).
>
>
> >
> > Patching the daemon
> > ---
> >
> > One of the great advantages of uWSGI_ is its ability to gradually
> > restart each
> > worker without loosing any request. For example, uWSGI_ can be
> > s

Re: uWSGI documentation

[Roberto De Ioris]

> That said i'd love to *not* have to put a 3 liners module in my
> project directory anymore. A runuwsgi command might not be the only
> way to solve this need.
>


Remember that you do not need those file anymore:

[uwsgi]
env = DJANGO_SETTING_MODULE=mysite.settings
chdir = 
module = django.core.handlers.wsgi:WSGIHandler()
...
...

Or you can do magic with placeholder like this:

[uwsgi]
my_django_app = mysite
env = DJANGO_SETTING_MODULE=%(my_django_app).settings
chdir = /apps/%(my_django_app)
module = django.core.handlers.wsgi:WSGIHandler()

(obviously this rules apply to xml,yaml,ldap,command line and so on...)


> uWSGI_ supports configuration through:
>
> * command line switches
> * ini files
> * xml files

yaml is supported too and you should mention environment variables, they are
used a lot on already available *BSD init scripts

Probably i would add a section about massive hosting of applications using
the Emperor (The Emperor doc is probably the only good one of all the
uWSGI project as it is not written by me :) )

http://projects.unbit.it/uwsgi/wiki/Emperor

One of the most-loved (by me too) feature of mod_wsgi is its
virtualhosting capability
tied-in with apache. uWSGI in the past forced you to manually manage a
instance for every app or use the PITA (but funny and hacky)
multiple-interpreters-way. The Emperor solves this problem elegantly and
with a lot of attention about clouding/hosting platforms.

>
> Starting the server
> ---
>
> Starting an uWSGI_ server is the role of the system administrator,
> like
> starting the Web server. It is *not* the role of the Web server to
> start the
> uWSGI_ server. This means:
>
> * the uWSGI_ server can be restarted or reloaded independently from
> the Web
>   server,
> * it is the role of the system administrator to make uWSGI_ to start
> on boot
>   or reboot: either through tools like supervisor or daemontools,
> either
>   directly at init level in a file like /etc/rc.local or /etc/conf.d/
> local


Nothing to say against this, but Cherokee (as an example) manages the
uWSGI processes itself (it is an exception to the rule, i do not know if
it is worth mentioning it).


>
> Patching the daemon
> ---
>
> One of the great advantages of uWSGI_ is its ability to gradually
> restart each
> worker without loosing any request. For example, uWSGI_ can be
> signaled that
> worker should reload the code after handling their current request (if
> any)::
>
> kill -HUP `cat /tmp/project-master.pid`


You can gracefully reload (in 0.9.7 tree) simply touching a file with
the --touch-reload =  option and (probably more important) you can
reload from the app itself using uwsgi.reload()


>
>
> Tipical gotchas:
>
> * if the socket is a file: the Web server process should have read,
> write and
>   execute permissions on the socket file



you should mention the --chmod-socket option here


> * uWSGI_ won't remove the socket and pidfile when it is interrupted,

here --vacuum option should be reported, but i will put enphasis on the
inhability to remove socket/pidfile if you "kill -9" the uWSGI stack

If you have some doubt please ask me or the official uWSGI mailing-list i
know that uWSGI official docs are really bad and not synced with the
current code :P

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

[Russell Keith-Magee]

On Sat, Apr 9, 2011 at 12:50 AM, Samvit  wrote:
> Hi my name is Samvit Majumdar. Im from New Delhi, India.Im pursuing
> undergraduate study in Birla Institute of Technology and
> Science,Pilani,India. My major is IT. Im in my second year.
>
> While working on a project using Django ( www.bits-apogee.org/2011/
> ) , I came across few ideas that can be incorporated in Django.

Hi Samvit,

The reason we ask people to post their proposals to django-dev is so
that they can get discussion and feedback *before* the deadline for
project submission passes. As it stands, this proposal has some major
question marks over it:

 * Do we want this feature at all?
 * Is it something that should be integrated into admin by default, or
should we just provide the extension points so that it can be
implemented as a third party option (like per-row permissions)
 * Technical issues: "How do you propose to manage the schema
alteration process for every Django project in existence?
 * Planning issues: You've allocated 6 weeks to define a single "Role"
model (as well as designing them, testing them in various ways, and
"debugging" them) -- but only 1 week to make the admin modifications.
I think you might have that scheduling the wrong way around.

As it stands, this isn't a very strong proposal. The votes aren't
final yet, but I don't like your chances of being selected for
Django's GSoC. If you'd posted this a week ago, you would have gotten
that feedback in time to make some modifications, and your chances
might have been a lot better.

Yours,
Russ Magee %-)

-- 
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: [GSoC2011] Integrate databrowse into admin

[M Stefan]

On 4/8/2011 2:48 AM, Russell Keith-Magee wrote:

On Fri, Apr 8, 2011 at 5:37 AM, M Stefan  wrote:

Hello everyone. My name is Stefan, and I'm a 19 years old student in Iasi,
Romania, at Faculty of
Computer Science. I've started programming as a young kid (I was about 8 or
9) and
have been programming since then. I've started with the silly mIRC scripting
and Visual
Basic and then moved on to various real programming languages (e.g. C, C++,
Python,
Javascript, PHP, C# etc.) and various projects (mostly as a freelancer and
on personal projects).
This is my second time to participate on GSoC (I also participated last year
for Boost) and I
would really like to have the chance to work on a major project again.

I would like to work on removing databrowse from django and implement its
features on admin.
Although I have worked plenty with Python and other MVC frameworks (mostly
PHP ones), I
haven't started learning django until recently. I've read some of
databrowse's source code and toyed
with it a little and I realize it's pretty limited in functionality and, as
has been said, has multiple unfixed
bugs and lacks maintenance. It is too limited to be used for any production
purposes,
and admin does a pretty good job for both production and dev phases.

In fairness, it's not really intended for "production" -- it's a data
exploration tool. It's also a tool that hasn't seen a lot of work
since it was initially added; hence the motivation to merge it with
admin.


A few important features of databrowse include read-only access to tables
and rows, filtering by possible values
of a field (such as filtering by calendar date for datetime fields or
filtering by any of the values that match for
at least one row) and automatically displaying one-to-many,many-to-one and
many-to-many relationships
between models. Looking through the source-code, I realize that not even the
obvious problems have been fixed:
For instance, when creating hyperlinks to objects,
datastructures.EasyInstanceField.urls attempts to call
_get_pk_call() on values returned by
datastructures.EasyInstanceField.values(), which might return
strings or even NoneType (this occurs, for instance, when you have a null
foreign key, which is normal
if you would like to, for example, store a rooted tree). The patch is
trivial, and I've attached it here.

If you've found a patch for a specific bug, then you should open a
ticket and attach your patch there.


That said, I would like to merge its functionality into admin. Users will
have separate permissions
for viewing (which will be granted implicitly with change/delete, it doesn't
make much sense to be able to
change/delete without viewing in a web app). There will be multiple ways of
viewing the data, one that
lists all the tables and their relationships, allowing to view all rows in a
table (with the now-lacking pagination)
and the rows related to it (via foreign keys), with the possibility of
filtering by each of the fields. Another way
of viewing the rows are in a tree-view, in which all rows that are
subordinated (via a foreign key) to other
rows will appear underneath and indented to the right of the parent row. The
rows can be either displayed
by their representation (__unicode__) or by some kind of table showing all
of their fields. Pagination will
be added here too. Rows whose all foreign keys are null will appear as
roots, and so will the rows who
don't have foreign keys (i.e. belong to a table w/ no foreign keys). All
others should appear as children
of at least one row (can appear as children to multiple rows in case the
relationships are many-to-many).
This data viewing interfaces will have means of adding, changing or deleting
rows, which will forward
to the admin interface. If, for instance, one clicks something like "add
child" on a row whose primary
key field is the foreign key of another table, then a row of that table will
be created, whose foreign
key will be set to this row's primary key.

I apologize for being so late with the proposal, I really wish I could have
written it earlier.
I'm planning on writing a timeline for the final version of the proposal,
but please let me know what
your opinion is first.

Well -- to be brutally honest: From a high level, the project is
interesting, and you appear to be roughly on the right track. However,
so far, your proposal is a fairly light elaboration of what Django's
GSoC wiki already gives you, and that's a long way from being an
proposal that is likely to be accepted. You're proposing a set of
fairly major modifications to admin, and all we have to go on is a
paragraph of loose descriptions of what you intend to do.

Time is running out for GSoC applications; if you want your proposal
to be taken seriously, you need to provide a lot more elaboration and
a timeline -- and quickly.

Yours,
Russ Magee %-)

I managed to add more details to my proposal and a timeline in time for 
the deadline. Thanks for the support.


Yours,
  Stefan M

--
You received th

Re: uWSGI documentation

[Mikhail Korobov]

Hi James,

Some notes:

> One of the great advantages of uWSGI_ is its ability to gradually
> restart each worker without loosing any request.

I think mod_wsgi in daemon mode is doing the same.

> Nginx provides the uwsgi module by default these days.

Stock nginx does not provide uwsgi module on latest CentOS, RedHat,
Debian and even on latest released Ubuntu by default. Ubuntu will
update default nginx to 0.8.x soon but on other OS'es 0.7.x or even
0.6.x will remain default for a long time.

> location / {
>uwsgi_pass 127.0.0.1:3000;
># in case of a socket file:
># uwsgi_pass unix:/tmp/yourproject.sock;
>}

According to this: http://www.iana.org/assignments/port-numbers 3000
port "SHOULD NOT be used without IANA registration. The registration
procedure is defined in [RFC4340], Section 19.9." because it is one of
"DCCP Registered ports". I don't know if this is a serious issue but
it seems that it is better to recommend port numbers above 49152 in
tutorials.

Thanks!

On 8 апр, 22:34, is_null  wrote:
> On Apr 4, 3:59 pm, Kristaps Kūlis   wrote:
>
> >   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'm unsure. Roberto's proposal is interresting: i could configure
> uwsgi in settings.py and then just run runuwsgi. Although that looks a
> little to much for django itself, it would be great in a pluggable
> django app.
>
> That said i'd love to *not* have to put a 3 liners module in my
> project directory anymore. A runuwsgi command might not be the only
> way to solve this need.
>
> On Apr 2, 4:44 pm, Łukasz Rekucki  wrote:
>
>
>
> > +1. More docs didn't hurt anybody. At least while there is someone to
> > maintain them.
>
> You can count on me (until death).
>
>
>
> > > 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 onuWSGI, not compare it
> > against other solutions. You also mention some features, but never
> > show how to enable/use them which is confusing.
>
> Thanks for your feedback, I did my best to take it in consideration
> while rewriting most of the documentation this week.
>
> (Some examples are still missing but most of it is there. Feedback is
> always appreciated)
>
> 
> How to use Django with uWSGI
> 
>
> .. highlight:: bash
>
> uWSGI_ is a fast, self-healing and developer/sysadmin-friendly
> application
> container server coded in pure C.
>
> .. _uWSGI:http://projects.unbit.it/uwsgi/
>
> Prerequisite: uWSGI
> ===
>
> `uWSGI wiki`_ describes
> several
> installation procedures. Using pip, the python package manager,
> installing any
> uWSGI_ version can be done with one command line. For example::
>
>     # install current stable version
>     pip install uwsgi
>     # or install LTS (long term support)
>     pip installhttp://projects.unbit.it/downloads/uwsgi-lts.tar.gz
>
> Prerequisite: general concept
> =
>
> uWSGI model
> ---
>
> uWSGI_ operates on a client-server model. Your Web server (ie. Nginx,
> Apache)
> communicates with a django-uwsgi "worker" process to serve dynamic
> contents.
> The Web server can communicate with the uWSGI_ process either:
>
> * directly by the uWSGI_ protocol through a socket created by uWSGI_,
> * or by proxying HTTP requests to the minimalist HTTP server built in
> uWSGI_,
>
> In the first case: the Web server can do uWSGI_ protocol (often with a
> module). It can then use either a Unix domain socket (a "named pipe"
> on Win32
> systems), or it can use a TCP socket. What you choose is a matterr of
> preference. Usually, a TCP socket is easier because connecting to a
> port
> doesn't require special permissions.
>
> In the second case, the Web server doesn't need to do uWSGI_ protocol.
> It just
> needs to be able to proxy HTTP requests to the HTTP server built-in
> uWSGI_.
> The procedure is the same than proxying any HTTP server. Note that the
> Web
> server is a "reverse proxy" in this case.
>
> Configuring the uWSGI server
> 
>
> In any case, when you set up your Web server, you'll just need to
> point its
> uwsgi or proxy module to the host/port or socket you specified when
> starting
> the uWSGI_ server.
>
> .. admonition:: Choosing the socket
>
>     The easiest is to set the socket to a high level (>1024) local
> port like
>     127.0.0.1:3000. If the socket is a file, the system administrator
> must

Re: Possible bug with DATABASE_ROUTERS?

[subs...@gmail.com]

I found I had another router that was being greedy.

On Apr 8, 12:15 pm, "subs...@gmail.com"  wrote:
> Hello everyone,
>
> I posted to the user's list but haven't heard anything. I am wondering
> if this sounds like it could potentially be a bug:
>
> http://groups.google.com/group/django-users/browse_thread/thread/253b...
>
> if this is due to my misunderstanding of routers, please forgive my
> posting here (but if you choose to grace me with a reply @ -users,
> thank you).
>
> -Steve

-- 
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: Sprints DjangoCon Europe

[Raphael Passini Diniz]

I live in Brazil, Belo Horizonte to be more precise, but far from RJ, about
6 hours by car.
If i can help in anything, plz, let me know.

2011/4/8 Wim Feijen 

> More news about the sprints!
>
> During the sprints we will have access to the Dialogue Cafe in de Waag
> building (see: http://www.dialoguecafe.org/). Dialogue Cafe offers
> facilities for video conferencing. Wouldn't it be great if we could
> sprint all over the world? Actually, up to now, two locations outside
> of Amsterdam have been opened, namely Lisbon (Portugal) and Rio de
> Janeiro (Brazil). In addition, Ramallah (India) will probably open in
> june, so maybe in time maybe not for the sprints.
>
> My question right now is: do you know any programmers in (the vicinity
> of) Lisbon, Rio de Janeiro or Ramallah? Who would be willing to attend
> to the sprints and possibly help in organizing the local communities?
>
> Please let me know. You can respond here or by private mail as well.
>
> Thanks!
>
> Wim
>
> --
> 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.
>
>


-- 
Atenciosamente Raphael Passini Diniz

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

Gsoc 2011 Proposal

[Samvit]

Hi my name is Samvit Majumdar. Im from New Delhi, India.Im pursuing
undergraduate study in Birla Institute of Technology and
Science,Pilani,India. My major is IT. Im in my second year.

While working on a project using Django ( www.bits-apogee.org/2011/
) , I came across few ideas that can be incorporated in Django.

Some of them are discussed below.


Roles in Django User model


While working on a project using Django, I came across many ideas that
can be incorporated in Django.

One of them is a concept of Roles.



A website has many users with various functions like manager, content
editor, administrator etc.

For each function we can have different set of data associated with
them .

eg :

  For a manager, one may need his contact number , address, workplace
etc.

  For content editor, one may need only contact number and not this
work address, home address etc.



Need :



  Currently we can only  associate 1 user profile class with a user
and call user.get_profile()

  This can be quite inconvenient when one is need of many profiles.



  Another way is to Inherit the User class.





Proposal :



  A new class Role can be created. The user model has to modified only
a bit as only one foreign key has to be added i.e. "role".

  Role class would look something like this :



 class Role():

  permissions = a list type entity or a Group ( which is
predefined )

  profile = a class associated with a role


...


  After this while developing we can create a new Role by inheriting
the above defined class :



   eg :
 ( Rough Draft )


 class Manager(Role):

  permissions = 'Managers' #a group with permissions

  profile = ManagerProfile


...
  the class ManagerProfile would look like:



 class ManagerProfile(models.Model):

  phone = models.IntegerField()

  address = models.TextField()

  mobile_no = models.IntegerField()

  





  so in this way while creating a user a role can be associated with
it, so only necessary data can be stored in the database.



Accessing profile :

The profile can accessed from user.get_profile(). This function would
be modifiled to get contents of the user.role.profile


Off-line Mode setting




Many time on production environments we make changes to the site. The
site goes through many development phases. There is sometimes few
hiccups while migrating from development to production environment.

Introduction of a off-line setting can be very useful in these cases.

OFFLINE = True  # setting sugessted

When its true all the views gets redirected to a single view named
offline. The template to be rendered can be named offline.html.
Administrators can access the site via admin interface. This setting
will not effect the admin application. Also when admins are logged in
they can view the site normally and changes can be made fast without
any inconvenience to other users on the site.


Changes to the Admin application

Select box in filters
When there are many ( > 100 ) filters on the right panel of the admin
view objects interface.
The  page gets indefinitely extended to and its quite inconvenient to
select one of them.
Instead a simple select box can be used if no. of elements is more
than 30( example ).

Admin view objects
The admin interface has no permission as “view objects” . This is
really userful feature and can be incorporated in Django.







Timeline


1st week :  Designing models for roles. Considering all aspects needed
to be included in the model.

2nd Week :  Writing the models. Dealing with all the key aspects of
it. Maitain backward compatibility

3rd  week  : Testing the written models in a development environment.
Note all furthur changes that may be required

4th week : Debugging the models.

5th week : Testing in production environment. Implementing it in a
real project. Also note all the
difficulties and errors faced.

6th week : Final composition of the model to be drafted.

7th week : Development on the Offline mode setting. Note down key
aspects and vulnerabilities.

8th week : Implementing the Offline mode setting.

9th week : Testing the offline setting in an actual project. And
debugging simultaneously.

10th week : Tweaking the admin app. Also survey what all developers
would like to include in the admin app for future and current
references.

11th week : Documentation of all the projects and changes.

12th week : Documentation and feedback.


So that is all that I would like to propose at this time. Any
suggestions , improvements and constructive  critisism is always
welcome.

Regards,
Samvit

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

[is_null]

On Apr 4, 3:59 pm, Kristaps Kūlis   wrote:
>   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'm unsure. Roberto's proposal is interresting: i could configure
uwsgi in settings.py and then just run runuwsgi. Although that looks a
little to much for django itself, it would be great in a pluggable
django app.

That said i'd love to *not* have to put a 3 liners module in my
project directory anymore. A runuwsgi command might not be the only
way to solve this need.

On Apr 2, 4:44 pm, Łukasz Rekucki  wrote:
>
> +1. More docs didn't hurt anybody. At least while there is someone to
> maintain them.
>

You can count on me (until death).

>
> > 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 onuWSGI, not compare it
> against other solutions. You also mention some features, but never
> show how to enable/use them which is confusing.

Thanks for your feedback, I did my best to take it in consideration
while rewriting most of the documentation this week.

(Some examples are still missing but most of it is there. Feedback is
always appreciated)


How to use Django with uWSGI


.. highlight:: bash

uWSGI_ is a fast, self-healing and developer/sysadmin-friendly
application
container server coded in pure C.

.. _uWSGI: http://projects.unbit.it/uwsgi/

Prerequisite: uWSGI
===

`uWSGI wiki`_ describes
several
installation procedures. Using pip, the python package manager,
installing any
uWSGI_ version can be done with one command line. For example::

# install current stable version
pip install uwsgi
# or install LTS (long term support)
pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz

Prerequisite: general concept
=

uWSGI model
---

uWSGI_ operates on a client-server model. Your Web server (ie. Nginx,
Apache)
communicates with a django-uwsgi "worker" process to serve dynamic
contents.
The Web server can communicate with the uWSGI_ process either:

* directly by the uWSGI_ protocol through a socket created by uWSGI_,
* or by proxying HTTP requests to the minimalist HTTP server built in
uWSGI_,

In the first case: the Web server can do uWSGI_ protocol (often with a
module). It can then use either a Unix domain socket (a "named pipe"
on Win32
systems), or it can use a TCP socket. What you choose is a matterr of
preference. Usually, a TCP socket is easier because connecting to a
port
doesn't require special permissions.

In the second case, the Web server doesn't need to do uWSGI_ protocol.
It just
needs to be able to proxy HTTP requests to the HTTP server built-in
uWSGI_.
The procedure is the same than proxying any HTTP server. Note that the
Web
server is a "reverse proxy" in this case.

Configuring the uWSGI server


In any case, when you set up your Web server, you'll just need to
point its
uwsgi or proxy module to the host/port or socket you specified when
starting
the uWSGI_ server.

.. admonition:: Choosing the socket

The easiest is to set the socket to a high level (>1024) local
port like
127.0.0.1:3000. If the socket is a file, the system administrator
must
ensure that the Web server process has read, write and execute
privileges
on that file.

uWSGI is highly configurable and thus there are many ways to start the
process. For example, uwsgi version 0.9.6.8 provides a hundred
switches.
This guide demonstrates the most important of them, but does not
intent to
substitute the official manual and online documentation.

uWSGI_ supports configuration through:

* command line switches
* ini files
* xml files

Managing the uWSGI server
-

The system administrator controls the worker process pool by sending
signals
to the master process. For example, the unix kill command sends such
signals.
uWSGI_ can write the master process id to a "pidfile". A "pidfile" is
a plain
text file containing just a process id.

Starting the server
---

Starting an uWSGI_ server is the role of the system administrator,
like
starting the Web server. It is *not* the role of the Web server to
start the
uWSGI_ server. This means:

* the uWSGI_ server can be restarted or reloaded independently from
the Web
  server,
* it is the role of the system administrator to make uWSGI_ to start
on boot
  or reboot: either through tools like supervisor or daemontools,
either
 

Possible bug with DATABASE_ROUTERS?

[subs...@gmail.com]

Hello everyone,

I posted to the user's list but haven't heard anything. I am wondering
if this sounds like it could potentially be a bug:

http://groups.google.com/group/django-users/browse_thread/thread/253b77110fb68a89

if this is due to my misunderstanding of routers, please forgive my
posting here (but if you choose to grace me with a reply @ -users,
thank you).

-Steve

-- 
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: Sprints DjangoCon Europe

[Wim Feijen]

More news about the sprints!

During the sprints we will have access to the Dialogue Cafe in de Waag
building (see: http://www.dialoguecafe.org/). Dialogue Cafe offers
facilities for video conferencing. Wouldn't it be great if we could
sprint all over the world? Actually, up to now, two locations outside
of Amsterdam have been opened, namely Lisbon (Portugal) and Rio de
Janeiro (Brazil). In addition, Ramallah (India) will probably open in
june, so maybe in time maybe not for the sprints.

My question right now is: do you know any programmers in (the vicinity
of) Lisbon, Rio de Janeiro or Ramallah? Who would be willing to attend
to the sprints and possibly help in organizing the local communities?

Please let me know. You can respond here or by private mail as well.

Thanks!

Wim

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

[trybik]

Please, first read the whole message thoroughly before going into the
prima balerina mode. I really appreciate your volunteer time work and
the need to control the chaos and would like to help out respecting
that. "Submission rejected as potential spam (BlogSpam says content is
spam (badip:state/blacklist.d/127.0.0.1))" is really to much hassle
for me. I will gladly submit a ticket if you please fix that.

As for now, again, feel free to submit the ticket or tackle the
problem directly, without too much bureaucracy involved (suggested).
No demands placed.

Best regards,
Mikołaj

On Apr 6, 11:01 pm, Jacob Kaplan-Moss  wrote:
> On Wed, Apr 6, 2011 at 3:22 PM, trybik  wrote:
> > Hi Łukasz,
>
> > On Apr 4, 8:43 pm, Łukasz Rekucki  wrote:
> >> It's best to report bugs on the tracker. Otherwise, they'll die in
> >> infinite depths of everyone's mailboxes.
>
> > that sounds like too much hassle for me. Please, feel free to report
> > this.
>
> No, you don't get to do this.
>
> If it's too much hassle for you to open a ticket, then it's too much
> hassle for us to work with you.
>
> We have thousands of people all with their own patches, feature
> requests, and support needs. We're going to prioritize the ones who
> are willing to meet us halfway, help out, and don't place demands on
> our volunteer time.
>
> Jacob

-- 
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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Matt Hoskins]

On Apr 7, 10:47 am, Julien Phalip  wrote:

> Hi Matt,
>
> Do you think this could be related 
> tohttp://code.djangoproject.com/ticket/11448
> ?
>
> If so, do the patches attached to that ticket help resolve your issue?
>
> Thanks,
>
> Julien

Hi Julien,

Thanks for your reply - from a quick squint at that ticket I don't
think it's related (options._name_map was populated with current
information, it's just that map doesn't have sufficient information to
allow setup_joins to differentiate between the reverse of O2O and the
reverse of ForeignKey). As you can see from a reply I've just made to
Russ I think the problem has gone away in Django 1.3 anyway (or at
least it's been masked by another change, so I can now use reverse O2O
in values and values_list with 1.3 without getting an error).

Regards,
Matt

-- 
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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Matt Hoskins]

On Apr 7, 8:59 am, Russell Keith-Magee 
wrote:
>
> I'd need to go spelunking through the code to be sure, but if this is
> happening, I'd be guessing it's oversight. From a quick scan of the
> test suite, I can't find an obvious test for values() on one-to-one
> fields.
>
> As for the reason for this; OneToOne keys are a degenerate case of
> foreign key, but in the reverse direction, they have a single value
> (as opposed to the multiple values of a reverse foreign key). As a
> result, the oversight would be failing to include reverse one-to-ones
> in the list of valid names, overriding the default interpretation for
> the ForeignKey from which they are inherited.
>
> So - it sounds like this should be reported as a ticket; If you could
> also reduce this to a test case that is integrated into Django's test
> suite (regressiontests/one_to_one_regress would be a good place,
> because it has o2o models ready to use), that would be very helpful.
>
> Yours,
> Russ Magee %-)

Hi Russ,

Thanks for taking a look at this. I knocked up a quick test case and
was surprised to find that it passed under Django 1.3 (I hadn't tried
testing under 1.3 before, but I'd checked the two sections of code in
1.3 that relate to the problem being triggered and they hadn't changed
so I was fairly sure it hadn't been directly fixed!).

After much rummaging around I eventually found that #5768
http://code.djangoproject.com/ticket/5768 has removed the restriction
on M2M being used in .values and .values_list (i.e. the call to
self.query.add_fields changed to say m2m were allowed) so the fact
that setup_joins is treating a reverse OneToOne the same as a reverse
ForeignKey (i.e. it's potentially many to many in nature) doesn't lead
to the exception being raised any more.

So alas if I log the bug and supply a test then the test will pass :).
It may not matter that the oversight I outlined exists if it can't
manifest as a problem now - although I suspect it's useful to have a
regression test on values() and values_list() referencing the reverse
of O2O in case of future changes. A test that does a deeper call to
queryset.query.add_fields() with allow_m2m set to False could be
written, but I guess that's a no-no as it's testing the implementation
rather than the public API.

Want me to log it as a bug and include the test that'll pass and some
notes explaining what's gone on? (I can, and have, run the same test
against Django 1.2.5 to prove the test fails where the problem hasn't
been masked by the change to the call to add_fields).

Regards,
Matt

-- 
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 : Templates Compilation , draft 2

[Andrey Zubko]

Hello, Russell Keith-Magee
Thanks for your advices.
*1. Detailed Timeline :*

   - Designing concept : this step requires fully design writing for
   achieving BACKWARD compatibility for all tags, and filters. Providing
   backward-compatibility is a simple task. I've described it earlier by using
   FilterExpression class.
   - Coding "template compilation" subsystem :
  - 4 days term - django.template.loader, django.template.loaders.* -
  adding support for importing already compiled templates.
  - 1 week term - implementing 'compile' method to
  django.template.Template class, in this method will be processed
calling of
  child nodelist compiling and writing to compiled template file.
  - 2 weeks term - implementing 'compile' method to django.templates
  - 1 weeks term - implementing 'compile' method to
  django.template.loader_tags Node-derived classes.
  - 3 days term - implementing support in
  django.template.FilterExpression and django.template.Variable.In 5
  weeks term will be produced such possibilities :
 1. compiling, writing, importing compiled tempaltes files
 2. support for compilation of default filters from
 django.template.defaultfilters, and default tags from
 django.template.defaulttags : , Node, Node-derived classes : TextNode,
 VariableNode, BlockNode, ExtendsNode, ConstantIncludeNode,
IncludeNode,
 AutoEscapeNode, CommentNode, CsrfTokenNode, CycleNode, FilterNode,
 FirstOfNode, ForNode, IfChangedNode, IfEqualNode,
RegroupNode, SsiNode,
 LoadNode, NowNode, SpacelessNode, URLNode, WidthRatioNode, WithNode.
  - 5 days term - implementing 'compile' method for
  django.template.defaulttags.IfNode and implementing compilation
support for
  django.template.smartif.
   - Writing unit-tests :
  - 1 week term - writing unit-tests for compilation process for
  django.template.defaultfilters.
  - 2 week term - writing unit-tests for django.template.defaulttags.
  - 4 days term - writing unit-tests for django.template.loader_tags.
  - 1 week term - writing unit-tests for compilation process for
  django.template.Template, django.template.loader,
django.template.loaders.*.
  Testing compiled tempates writing,import'ing and raw template compiling.
   - 1-2 weeks term - resolving all errors founded by using unit-tests.
   By this step I will produce fully tested template compilation code.
   - 3-5 weeks term - optimization of written code

*2. Armin Ronacher has good template engine that supports template
compilation, and other features. I can not argue against his template engine
solution. But, society should be pointed on :*

   - The default syntax of Jinja2 matches Django syntax in many ways.
   However this similarity doesn’t mean that you can use a Django template
   unmodified in Jinja2. For example filter arguments use a function call
   syntax rather than a colon to separate filter name and arguments.
   Additionally the extension interface in Jinja is fundamentally different
   from the Django one which means that your custom tags won’t work any
   longer.
   - Armin Ronacher wrote about backward-compatibilty: > Are you planning on
   keeping the API for registering template tags > compatible?
   (django.template.Library.register.tag) It will be supported because
   otherwise upgrading won't be possible, but how well this works in detail
   would have to be investigated and what a cleaner implementation looks like.
   Jinja2 has an expression parser and encourages people to create a AST that
   does what they want in extensions. However in Jinja2 I never encouraged
   people to write custom tags so the API is very limited there.  As for
   me, he haven't made decision how it would be looked like in Django. I have
   already proposed solution of template subsystem's improvement.
   - My solution will come with django 'out of the box' against Armin
   Ronacher solution.


On Fri, Apr 8, 2011 at 4:23 AM, Russell Keith-Magee  wrote:

> On Fri, Apr 8, 2011 at 9:15 AM, Andrey Zubko  wrote:
> > Hello,
> > I'm Andrey Zubko, student faculty of Computer Science in Zaporozhye
> > State Engineering Academy. I'm senior chief developer of a local
> > Internet Service Provider "Telza" which provides Internet and
> > telephony services. My responsibilities includes enhancing, improving
> > existent Billing system that is written by myself.
> >
> > In GSOC program I want to improve template subsystem by integrating
> > template compilation into python bytecode.
> >
> > Goals and challenges
> >  Integrating of template compilation has 2 goals. The first goal and
> > the chief goal is to provide backward-compatibility to  templates,
> > custom tags, custom filters  that are already  written.  The second
> > goal is to minimize modifications of Django sources to provide more
> > stability and faster integrating in trunk.
> > Implementation
> > Support of