On 27 May 2010 05:33, Stephen Hansen <apt.shan...@gmail.com> wrote:
> On May 25, 9:18 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>> The list of encodings is calculated when Python is initialised.
>
> This is only partially true. The initial list is indeed calculated,
> but then you can register new encodings at any point you would like
> later. That's what I'm doing: I'm registering an encoding. It is
> successful.
It wasn't stated clearly in your post that you were explicitly
registering the codec. If you are indeed registering the codec
explicitly, then that potentially gets around the Python
initialisation needing to be associated with the virtual environment.
I would need to look though at how manual registration occurs and what
that actually does.
> And then, later on, the encoding is no longer registered. Something
> strange has happened.
>
>> When you use virtual environments with mod_wsgi and add its location
>> by using WSGIPythonPath for embedded mode, python-path option for
>> daemon mode, or calling site.addsitedir(), or modifying sys.path in
>> WSGI script it is too late and that is long after Python is
>> initialised.
>>
>> The way around this is is point Python used by mod_wsgi directly at
>> the virtual environment so it uses it on startup and thus can find the
>> encoding. This is done using the WSGIPythonHome directive. See:
>
> I've already handled this entirely, this issue has nothing to do with
> PythonHome (the mod_wsgi or environment variable). I think I'm not
> expressing myself well here.
>
> I have a wsgi script which is approximately:
>
> import site
> site.addsitedir(r'C:\blah\virtualenv\Lib\site-packages')
> import os, sys, codecs
> sys.path.append(r'C:\blah\virtualenv\project')
>
> import apt
>
> try:
> codecs.lookup("easyascii")
> print >>sys.stderr, "Successful."
> except codecs.LookupError:
> print >>sys.stderr, "LookupError"
> except ex:
> print >>sys.stderr, repr(ex)
>
> from paste.deploy import loadapp
>
> application = loadapp('config:C:\\blah\\virtualenv\\project\
> \production.ini')
>
> This script works perfectly. Easyascii is available. Perhaps setting
> WSGIPythonHome would make me not have to do so much path-fiddlings,
> and I'll look into it-- but that's neither here nor there. In all
> subsequent code (specifically, in the project's application code which
> is later called), everything can find everything it needs to. "import
> apt" works everywhere: the paths are all correct.
>
> The problem is, in the wsgi: codecs.lookup("easyascii") works entirely
> fine. It works because "import apt" does (among a couple other things)
> some initial setup when its imported, including calling
> codecs.register(find_easyascii). Thus, anytime after you 'import apt',
> you should be able to do u"Hihi".encode("easyascii").
>
> Unfortunately, at some point later on, when mod_wsgi is calling into
> my Pylons application, long after one has done "import apt" --
> suddenly "easyascii" doesn't exist anymore. Timing wise, you're
> talking about when Python was initialized vs when the wsgi script is
> run -- but I'm talking about when the wsgi script is run I'm
> *registering* easyascii so it works, but then later in the actual wsgi
> application, its somehow not.
>
> I sort of have a workaround now, where I make sure to re-force the
> registration in a couple places. But on staring at this thing for
> awhile, I sort of suspect it has something to do with mod_wsgi using
> sub-interpreters of Python. And that said sub-interpreters may not be
> sharing the codecs registry among them. So, the apt\__init__.py is
> executed once in the first/main interpreter, modifying the codecs
> registry, but the sub-interpreters don't get their registry modified.
> At least, this is the only theory I can come up with that even vaguely
> makes sense.
It is a misconception, albeit not very common, that each request is
handled in a separate sub interpreter. This isn't the case. All
requests for a specific WSGI application should be handled in the same
interpreter instance in memory of any particular process handling the
request. One way this wouldn't be the case though is if you mucked up
the Apache configuration and used WSGIScriptAliasMatch when you
shouldn't and didn't use it correctly.
There is still a difference between main interpreter and sub
interpreter however. The main interpreter is the first interpreter
created. Sub interpreters are additional interpreter instances within
the same process which are created to hold different WSGI
applications. By default WSGI applications are given their own
separate sub interpreter, but in some cases it is necessary to force
the WSGI application to run in the main interpreter. This is usually
where third party C extension module is not designed to work with sub
interpreters.
As such, you might try adding:
WSGIApplicationGroup %{GLOBAL}
This will force WSGI application to run in main interpreter.
Try that and see if that makes a difference.
Graham
>> The documentation is actually misleading and is is now enabled on
>> Windows, but have heard mixed reports about it working and don't
>> understand what Windows is doing so haven't advertised it as working
>> on Windows for sure.
>
> Thanks for pointing this out. It might simplify some path-twiddling.
>
> --S
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to modw...@googlegroups.com.
> To unsubscribe from this group, send email to
> modwsgi+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to modw...@googlegroups.com.
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
