I have a strange issue with my Django Apache Wsgi setup. I recently moved my site to a different server. Unfortunately now the encoding is somewhat messed up. When I run a command like this:
barcode.generate_barcode("ean", "1341341234234")
the resulting image will show some special character between every digit, typically for some endocing issue. I guess it is using two bytes instead of one to represent each char or something similar.
If I run the same setup with django ./manage.py runserver comand. The resulting image is fine, no special characters added.
So I came to the conclusion this must be something with my apache2/mod_wsgi setup. But the versions are identical to my old setup, i.e. debian 6, apache2.2, mod_wsgi 3.3.2.
I would like to try a newer version of mod_wsgi but compilation fails.
Can anyone point me in the right direction to where this encoding error might have its cause? To my understanding the WSGI context somehow loads the entire python script with a wrong encoding, otherwise I cannot explain why a hardcoded string would turn out wrong on an image.
In Apache conf.d/charset:
AddDefaultCharset UTF-8
In my vhost additionally:
AddDefaultCharset UTF-8
In apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Envvars is used in apache runlevel script:
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi
I also tried to hardcode overwrite env vars in the runlevel script.
In my wsgi file:
import sys
reload(sys)
sys.setdefaultencoding('utf-8')
But nothing seems to help. My image is still generated with broken encoding.
An upgrade of mod_wsgi to version 3.4.0 fixed it.
You can use the option lang or locale to the WSGIDaemonProcess clause.
See in https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html
Related
I'm far from Python expert, so please bear with me.
I'm using Slack python bot library, which utilizes module loading to execute users code.
I noticed a weird thing - when I launch my script, it says ImportError: Import by filename is not supported on a line self.module = __import__(name) (where name is relative path to the Python file). I don't quite understand the problem, because the owners of the library test their code with both 2.x and 3.x Python, and it DOES work on TravisCI.
I'm using Python 2.7.8 on Windows 7.
How do I fix the problem? I suspect something on my system is wrong. I read similar questions on SO and worked around the issue by using imp.load_source, but I would like to get to the bottom of it.
P.S. It also works if I upload it to Heroku, which by default runs 2.7.12
I've found a lot of posts on Macports/Django install issues but none seem to quite address my situation.
Installed Django using Macports from the command line using
sudo port install py27-django
This seemed to work fine. I opened up IDLE and was able to import django. The following bit of code
import django
from django.core import management
print django.VERSION
returns
(1, 5, 1, 'final', 0)
Which I take to mean I have the final version of Django 1.5.1 installed. So, all seems to be well.
However, now I switch over to my Django tutorial to get learning and I am asked to type this into the command line to confirm that Django is installed:
python -c "import django; print(django.get_version())"
and get the following error:
> File "<string>", line 1, in <module> ImportError: No module named
> django
Some other bits of data. Here's my $PATH:
/Library/Frameworks/Python.framework/Versions/2.7/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
Finally, the command
django-admin.py startproject mysite
returns
-bash: django-admin.py: command not found
But the command
django-admin-2.7.py startproject mysite
works (creates a new directory called mysite in the working directory). I read somehwere that Macports renames the django-admin file.
I've only been working with Unix for a few weeks so this is a bit confusing. It seems like I have Django on my system, but perhaps the python I am trying to access from my command line is a different python from that which Macports uses.
Any help appreciated!
Dennis
You will need to set your PYTHONPATH environment variable from your terminal to reference your django install. IDLE probably did this for you, but in another shell you'll need to set it. You can set it in your terminal permanently by setting it in ~/.bashrc or ~/.bash_profile (or whatever your terminal shell is).
Your PATH starts with /Library/Frameworks/Python.framework/Versions/2.7/bin so when you type python you get the python in that directory which is the Apple supplied one nut you have installed Django for the Macports one so python does not see it.
To fix you need to have /opt/local/bin earlier on the path than the /Library one. even better remove that /Library entry and use port select python ... to choose which python to run the Macports 2.7 or Apple's or others
As for the django-admin-2.7.py issue, Macports allows you to have several versions of python at once so code depending on eth version has the version add into the script names e.g. you could have a django-admin-2.6.py as well if you installed the py26-django package. This also applies to python itself however python also adds into the port select mechanism so you set a default version.
I'm using Gramps 3.3.1 under Ubuntu 12.04 and trying to in Django Export/Import. The install is okay, but when I look at the installed addons, it says that it failed, with reason: "No module named web.settings".
I cann't for the life of me figure out how to fix this. I'm assuming that it's this line in the python script:
import web.settings as default_settings
Anyone have any ideas? I'm trying to get this data out and into a MySQL database, but I can't seem to.
Thanks!
When you run into an error where Python tells you "No module named blah" it really means it can't find "blah".
I would check your pythonpath and the filesystem permissions on the stuff in your path.
Edit
Your issue seems to be a known issue: http://www.gramps-project.org/bugs/view.php?id=5464
It's caused by not running Gramps from source, near as I can tell. It doesn't look like a Python Path issue, so much as the Gramps Django devs making assumptions where your Django settings would be (but I could be wrong).
As for Python Path, there's plenty of resources describing how to. The simplest way to check your Python path is to run echo $PYTHONPATH in a terminal. If you don't see it there, Python might not find it.
I'm trying to get an existing Django project to work on my mac.
I managed to configure everything and opening the project in PyCharm.
When I run I get the error:
TemplateSyntaxError at /
Caught BundleError while rendering: 'stylesheets' not found (using staticfiles finders)
We use Django 1.3 and Webassets 0.7 (just updated from earlier versions).
I have an assets.py defined in my application folder defining the various bundles.
Any suggestions on solving this?
EDIT: Ok, a bit further ... I added my project.assest to settings and now I don't have the Bundle error. I do still have another problem:
Caught BundleError while rendering: 'styles/libs/jquery-ui-timepicker-addon.css' not found
Path look ok, collectstatic works, copies, file is in place ...
any suggestions?
A project-wide assets.py (as opposed to one in an app-directory) is no longer automatically read, you need to define such files through a ASSETS_MODULES setting now.
If you are using staticfiles, pay attention to the fact that the staticfile finders will not be used unless Django is in debug mode (settings.DEBUG=True). In production mode, webassets will assume that collectstatic has been run first.
In settings.DEBUG=True mode, the reverse is true: ONLY the Django staticfile finders will be used. You could try opening a shell (./manage.py shell) and see if the following finds your file:
from django.contrib.staticfiles import finders
finders.find('styles/libs/jquery-ui-timepicker-addon.css')
If it does, then so should webassets.
I had a similar error arise
'[BUNDLE_NAME]' not found (using staticfiles finders)
This wasn't a very helpful message, so ended up looking into ./manage.py shell and running
>>> from django.conf import settings
>>> from [ASSETS_FILE_PATH.assets] import [BUNDLE_NAME]
>>> [BUNDLE_NAME]
If this isn't there it may give you another message.
I have a custom django filefield that makes use of sox, a commandline audiotool. This works pretty well as long as i use the django development server. But as soon as i switch to the production server, using apache2 and mod_wsgi, mod_wsgi catches every output to stdout. This makes it impossible to use the commandline tool to evaluate the file, for example use it to check if the uploaded file really is an audio file like this:
filetype=subprocess.Popen([sox,'--i','-t','%s'%self.path], shell=False,\
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
(filetype,error)=filetype.communicate()
if error:
raise EnvironmentError((1,'AudioFile error while determining audioformat: %s'%error))
Is there a way to workaround for this?
edit
the error i get is "missing filename". I am using mod_wsgi 2.5, standard with ubuntu 8.04.
edit2
What exactly happens, when i call subprocess.Popen from within django in mod_wsgi? Shouldn't subprocess stdin/stdout be independent from django stdin/stdout? In that case mod_wsgi should not affect programms called via subprocess. Is it possible to use a commandlinetool like that from mod_wsgi?
Add debug to your program to log to stderr the value of 'self.path' to ensure it is actually set to something. The message 'missing filename' suggest it may be empty. Also be aware that when running on Apache/mod_wsgi you must use absolute path names to files because the current working directory will not be the project directory like with the Django development server. Finally, Apache runs as a special user, so it needs to have appropriate read and/or write access to the directories you need it to access/write to. The path and access issues are documented in:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
BTW, for stdout issues, you really should upgrade to mod_wsgi 3.3. Read:
http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html