ImportError: No module named django.core.wsgi even if sys.path contains my virtualenv

[Giovanni Allegri]

I'm getting mad with this error.
I've setup Apache and wsgi configuration as usual, but this time I'm on 
CentOS instead of Debian, and I don't know it very well.
Anyway, I tried all the ways to give mod_wsgi the chance to peak from my 
virtualenv libraries, both setting them with python-path argument to 
WSGIScriptAlias, and using site.addsitedir in my wsgi module.
Printing sys.path gives me all the possible folders:

['/var/www/vhosts/vzqn-znxs.accessdomain.com/httpdocs/imn', 
'/home/giohappy/.virtualenvs/django/lib64/python2.6', 
'/home/giohappy/.virtualenvs/django/lib64/python2.6/site-packages', 
'/usr/lib/python2.6/site-packages/distribute-0.6.49-py2.6.egg', 
'/usr/lib/python2.6/site-packages/pip-1.4.1-py2.6.egg', 
'/usr/lib64/python26.zip', '/usr/lib64/python2.6', 
'/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', 
'/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', 
'/usr/lib64/python2.6/site-packages', '/usr/lib/python2.6/site-packages', 
'/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info', 
'/var/www/vhosts/vzqn-znxs.accessdomain.com/httpdocs/imn', 
'/home/giohappy/.virtualenvs/django/lib/python2.6/site-packages']

but still I get  ImportError: No module named django.core.wsgi

Could you help to sort it out? 
giovanni

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/00266e62-34b1-49d8-a981-761c374568a9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: SimpleLazyObject for request.user not correctly evaluated inside RequestContext

[giovanni allegri]

Hi German,
thanks for the reply. I apologize for the delay, but I didn't receive the 
notification :(
I've definetly improved the form workflow defining a validator inside my 
form. My validator check avoids the IntegrityError from Postgres.

Anyway, in case such an error happens, how should one manage it? How to 
reference the current transaction to roll it back?

giovanni

Il giorno sabato 7 settembre 2013 04:02:03 UTC+2, Germán Larraín ha scritto:
>
> What DB engine are you using? If it is PostgreSQL, you need to roll back 
> the transaction after a database error exception (e.g. IntegrityError).
>
> By the way, I think what you are doing is wrong. If the form data is 
> invalid, then you need to call . form_invalid
>
> On Friday, September 6, 2013 11:41:34 AM UTC-5, giovanni allegri wrote:
>>
>> I've opened a new thread, which relates to a previous 
>> one<https://groups.google.com/forum/#!topic/django-users/Ng0jocuFdqw>from me.
>> Digging into a wired behaviour in a FormView I've arrived to the 
>> following problem:
>>
>>  - In my "form_valid" method I need to manage exceptions situations.
>>  - In case of an exception I want to pass the response flow to an 
>> external method, in an other module
>>  - This external method returns a "render_to_response", in which I also 
>> pass a RequestContext instance built from the "FormView.request" object.
>>
>> Sometihng like this (I past a simplified version)
>>
>> class ProjectCreateView(FormView):
>>
>> def form_valid(self, form):
>> try:
>> 
>> except IntegrityError as e:
>> return render_error(_('A project with the same title already 
>> exists'),self.request)
>>
>> def render_error(msg,request):
>> #__dummy__ = request.user.is_authenticated()
>> data = {'error':{'msg':msg}}
>> return 
>> render_to_response('generic_error.html',data,context_instance=RequestContext(request))
>>
>> This causes a DatabaseError, because it crashes when it reaches the 
>> user.is_authenticated template variable. The crashed seems to be caused 
>> because of the SimpleLazyObject around the User instance. It seems it's not 
>> correctly setup, or whatelse... I don't know.
>>
>> This problem disappears if I use the __dummy__ variable in the previous 
>> snippet.
>> This call seems to make the SimpleLazyObject "prepared" for later calls 
>> (within the context processors).
>>
>> Why does this happen???
>> It never happens in other view and generic views I'm using in my project. 
>> What's wrong with the form view?
>>
>> Notice that 
>>
>> 1 - the same happens even if I set self.template_name and call 
>> self.render_to_response.
>> 2 - it doesn't happen during the normal form view workflow
>>
>> Giovanni
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: call to render_to_response with RequestContext within a Generic View causes DatabaseError when resolving the user.is_authenticated template variable

[giovanni allegri]

I don't know what is happening but I've solved with a workaround:

dummy = self.request.user.is_authenticated()

calling is_authenticated before returning render_to_response solves the 
problem, because request.user is "casted" to the actual user instance, 
instead of remaining a SimpleLazyObject.

I hope to understand why it happens one day...

giovanni

Il giorno venerdì 6 settembre 2013 16:10:22 UTC+2, giovanni allegri ha 
scritto:
>
> The problem seems to be related with SimpleLazyObject, wrapping the 
> auth.user.
> If during debugging I access the function, everything works fine. It's 
> enough to have the Variables windows open in PyDev.
> If I do not access it, it isn't resolved to the actual user instance (in 
> my case AnonymousUser), and then the template variable lookup fails. I 
> don't know exactly when, but it fails...
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

SimpleLazyObject for request.user not correctly evaluated inside RequestContext

[giovanni allegri]

I've opened a new thread, which relates to a previous 
onefrom me.
Digging into a wired behaviour in a FormView I've arrived to the following 
problem:

 - In my "form_valid" method I need to manage exceptions situations.
 - In case of an exception I want to pass the response flow to an external 
method, in an other module
 - This external method returns a "render_to_response", in which I also 
pass a RequestContext instance built from the "FormView.request" object.

Sometihng like this (I past a simplified version)

class ProjectCreateView(FormView):

def form_valid(self, form):
try:

except IntegrityError as e:
return render_error(_('A project with the same title already 
exists'),self.request)

def render_error(msg,request):
#__dummy__ = request.user.is_authenticated()
data = {'error':{'msg':msg}}
return 
render_to_response('generic_error.html',data,context_instance=RequestContext(request))

This causes a DatabaseError, because it crashes when it reaches the 
user.is_authenticated template variable. The crashed seems to be caused 
because of the SimpleLazyObject around the User instance. It seems it's not 
correctly setup, or whatelse... I don't know.

This problem disappears if I use the __dummy__ variable in the previous 
snippet.
This call seems to make the SimpleLazyObject "prepared" for later calls 
(within the context processors).

Why does this happen???
It never happens in other view and generic views I'm using in my project. 
What's wrong with the form view?

Notice that 

1 - the same happens even if I set self.template_name and call 
self.render_to_response.
2 - it doesn't happen during the normal form view workflow

Giovanni




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: call to render_to_response with RequestContext within a Generic View causes DatabaseError when resolving the user.is_authenticated template variable

[giovanni allegri]

The problem seems to be related with SimpleLazyObject, wrapping the 
auth.user.
If during debugging I access the function, everything works fine. It's 
enough to have the Variables windows open in PyDev.
If I do not access it, it isn't resolved to the actual user instance (in my 
case AnonymousUser), and then the template variable lookup fails. I don't 
know exactly when, but it fails...


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

call to render_to_response with RequestContext within a Generic View causes DatabaseError when resolving the user.is_authenticated template variable

[giovanni allegri]

I don't know if I'm following a wrong pattern in the context of Django. 
Inside my class views I need manage exceptions and I would like to pass the 
response workflow to an external method (my exceptions module). In my call 
I pass my ClassView.request variable to be able to use request context 
processors.
I paste an excerpt, where I do the render_to_response call directly from 
the form_valid method, just to test it.

class ProjectCreateView(FormView):
"""Create view."""
(...)

def form_valid(self, form):
"""Form and logic behind project creation."""

project_file = form.cleaned_data['project_file']
thumbnail = form.cleaned_data['thumbnail']
description = form.cleaned_data['description']

try:

except IntegrityError as e:
data = {'error':{'msg':_('project_overwrite_error')}}
return 
render_to_response('generic_error.html',data,context_instance=RequestContext(self.request))
except Exception as e:
return HttpResponse(e)

return HttpResponseRedirect(self.group.get_absolute_url())

(...)


Passing the RequestContext instance causes a DatabaseError, raised when it 
tries to test the user.is_authenticated template context variable.

I've noticed that when used in a basic view method, the resolution of 
user.is_authenticated is called only once, while it's hit twice in the case 
of the generic view. I don't know if it can be the source of the error...

Another strange thing is that it doesn't happen if I debug with a 
breakpoint inside the view dispathc method. Wired!

Here it is the stacktrace: https://gist.github.com/anonymous/6460412

First, I would like to understand why this happens.
Second, how should Itransfer the response flow outside a generic view? It 
works fine until I don't ask for the user variable, so I suppose there 
should be a cleaner way to manage the control tranfer.

Would you help me to solve the issue?
Thanks a lot,
Giovanni

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

post_syncdb handler never called in an app without models?

[giovanni allegri]

I premit that I've never used Django signals, so forgive if it's a trivial 
question.
I have an app without models (models.py empty), but I would like to add custom 
DB data after every syncdb. I thought I could use the post_syncdb signal to 
connect my handler method. I wrote it inside management.py and I see that this 
module is get called during syncdb (I used pdb.set_trace to test it), though 
the handler method is never called.
Does post_syncdb handlers get called only if a model is defined?

Thansk for your help.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/3IZxH6dMXjkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.