I’ve had some ongoing problems with PyCharm support for Django since the 1.7 release. Here is a summary.
The entire app failed to run under Apache. This caused some moments of terror. The WSGI file needed to be edited.
This code started on version 1.3. The old WSGI configuration worked until 1.7. This discussion thread described the behaviour, which bites projects started pre-1.4. See also Issue #23437 describes the WSGI problem, and the official release notes under app-loading changes.
The correct call to initialize WSGI is:
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
Tests in PyCharm broke. This a case of being bitten by older code again. Django uses the standard Python unittest module now. I had to go through dozens of files and tweak the import statements.
Update: LH asked for more information.
In my unit testing, I used the old-style Django test classes and had import statements like:
from django.test import TestCase
which must be changed to:
from unittest import TestCase
in order to use the built-in Python unit testing core.
This is kind of annoying. The problem isn’t so much PyCharm itself but Django “fixed” a long-standing “bug”. Now what used to work fine doesn’t. Per the app-loading changes in the 1.7 release notes, one must, every time they start the Django console from within PyCharm, execute the following commands:
This became annoying enough I hacked the Django helper
and added the two lines to that file. Problem resolved.
I spent some time with a colleague from South Africa yesterday. He’s a long-time Windows user that writes in Java. He has a new MacBook Pro, and we scratched our head why Apache+mod_jk+Tomcat was blowing up on him.
The first thing we had to get right was the JAVA_HOME variable. If it’s not set right when compiling mod_jk, you’re out of luck. On OS X there is a program that spits out the right value. We put the following in his ~/.profile. Please note the back ticks (accents graves) to run the java_home program.
With $JAVA_HOME set correctly, compiling mod_jk was straightforward. Download the mod_mod_jk tarball, unpack it, and change directories to the native subdirectory. The following should work cleanly.
$ ./configure --with-apxs=/usr/sbin/apxs $ make clean ; make $ sudo make install
Be aware that OS X Lion has some lines (commented out) for support for mod_jk. Be sure to uncomment those lines. Previous versions of OS X don’t have these lines, so you’ll just add the load module directive and Jk* commands in the usual places.
That’s it, really. Once JAVA_HOME and the Apache configuration file were straightened out, things worked.
I installed a new WordPress blog today on a server. The site is served by Apache using virtual hosting. I kept getting 404 errors trying to access any page that required mod_rewrite, pretty much other than the home page and administrative pages.
It turned out that I forgot the following in the Apache httpd.conf file:
... Options +FollowSymlinks AllowOverride FileInfo
I don’t monkey with the Apache configuration file enough to keep this information accessible in my brain. Here are some personal notes.
I set up a new LAMP server yesterday. Today I added some name-based virtual hosts to the configuration file, but was getting the following warning when restarting Apache:
[warn] _default_ VirtualHost overlap on port 80, the first has precedence
This warning was being triggered because I had not told Apache to use name-based virtual hosting. To enable name-based virtual hosting, locate and uncomment the NameVirtualHost directive in the Apache configuration file.
The Apache documentation site has information about setting up name-based virtual hosts. You can also find the details for the NameVirtualHost directive.