Step-by-Step: Installing Django

Being the Django and Python zealot that I am, I often find myself trying to convert those around me to this awesome development paradigm. Once I break them, these people often ask me a lot of questions about Django. Over the past few months I've noticed that one of the biggest sticking points for people who are new to Django is actually getting it up and running to begin with. In response, this is the first in a series of articles dedicated to getting Django up and running.

What is Django?

The Django Web site describes Django as "a high-level Python Web framework that encourages rapid development and clean, pragmatic design." Basically, Django is just about the most amazing thing for Web development. I have tinkered with several different Web technologies, but nothing seems to even come close to what Django can do for me.

What is Python?

Python is a programming language used in numerous aspects of computing these days. It has a very simple yet powerful syntax. It's an easy language for beginners to pick up, but it provides adequate levels of power for the more experienced developers out there. If you have never programmed anything before, or you have dabbled with something like BASIC, Python should be fairly straightforward. If you are a programming veteran, but have only worked with languages like C, C++, Java, etc, you might struggle a bit with the syntax of the language. It's not difficult to overcome the differences in a couple hours of hands-on development.

Let's get started.

Installing Python...

Having Python installed is critical--Django does not work without Python. I'm guessing that you're relatively familiar with the procedures for installing software packages on your particular operating system. However, I will share a few notes to point you in the proper direction if you're lost. If nothing else, just head over to the Python download page to download anything you need to install Python. I whole-heartedly recommend using the latest stable version of Python for Django, but you should be able to get by with as early a version as 2.3.

...On Windows

Simply grab the latest version of the Python installer. It is currently version 2.5.2. Once the installer has downloaded successfully, just run through the installation wizard like any other setup program.

...On Mac OS X

Recent Mac OS X computers come with Python pre-installed. To determine whether or not you actually have it, launch the Terminal (Applications > Utilities > Terminal) and type python -c "import sys; print sys.version". If Python is already installed, you will see the version you have installed. If you have a version that is less than 2.3, you should download the newest version. If you don't have Python installed, you will get a "command not found" error. If you're in this boat, just download the latest version of the Python Universal installer and install it.

...On Linux

Most Linux distributions also have Python pre-installed. Just like with Mac OS X, you can check to see by opening up a terminal/konsole session and running the command python -c "import sys; print sys.version". If you have Python installed, you will see its version. If you get an error message when running that command, or you have a version earlier than 2.3, you need to download and install the latest version of Python.

If you're running a Debian-based distribution (like Ubuntu, sidux, MEPIS, KNOPPIX, etc), you can probably use sudo apt-get install python to get Python. If you're running an RPM-based Distribution, you can probably use something like Yum or YaST to install Python.

A sure-fire way to install Python on any Linux system, however, is to install from source. If you need to do this, you simply:

  1. download the source for the latest version of Python
  2. extract it: tar jxf Python-2.5.2.tar.bz2
  3. go into the newly-extracted directory: cd python-2.5.2
  4. configure it: ./configure
  5. compile it: make
  6. install it: make install

(I've only installed Python from source one time, so I might be wrong)

Setting Up Your PYTHONPATH...

Generally speaking, if you didn't have Python installed before starting this tutorial, you will need to setup your PYTHONPATH environment variable. This is a variable that lets Python know where to find useful things (like Django).

...On Windows

  • Open up your System Properties (Win+Break or right click on "My Computer" on your desktop and select Properties)
  • Go to the "Advanced" tab
  • Click the "Environment Variables" button
  • If you have permission to change system variables, click the "New" button in the bottom pane. Otherwise, create the PYTHONPATH variable for your user account using the "New" button in the top (User variables for [username]) pane.
  • Set the variable name to PYTHONPATH
  • Set the variable value to C:\Python25\Lib\site-packages (replace C:\Python25\ with whatever it is on your system if needed)
  • Save it

You may also need to add the python executable to your PATH. If you can successfully run python from a command prompt window, you don't need to worry about it.

If you can't run python from a command prompt, follow the procedure above, but use the PATH variable instead of PYTHONPATH. PATH most likely already exists, so you just need to append/prepend the existing value with something like C:\Python25\ (again, this might need to change depending on where you installed Python)

...On Mac OS X

Your PYTHONPATH should already be setup for you.

...On Linux

Usually you just need to edit your ~/.bash_rc script to setup your PYTHONPATH environment variable. Go ahead and open that up in your preferred text editor and make sure there's something in it like:

export PYTHONPATH=/usr/lib/python2.5/site-packages:$PYTHONPATH

Save any changes necessary and run the following command:

source ~/.bash_rc

This will take care of updating your current session with any changes you made to your ~/.bash_rc.

Installing Django

Once you have Python and have verified that you have version 2.3 or later, you are ready to install Django. Currently, the latest stable release is 0.96.1, but this is grossly out-dated. Django 1.0 will be released on September 2nd 2008, so the "unstable" copy of Django is pretty close to what 1.0 will have to offer. There are some incredibly useful improvements in the unstable version that I don't think I could do without anymore, so that's what I'll talk about installing here.

First, you need to have a subversion client. On Windows, the most popular one is called TortoiseSVN. On Mac OS X, I have played with a few, but I think Versions is a pretty decent one. Linux also has several to choose from, but if you're using Linux, you're probably going to use the command line anyway (right?).

For brevity, I will just use the subversion commands necessary to accomplish this task (instead of discussing all GUI interfaces to subversion).

The exact location that Django should be installed differs from system to system, but here are some guidelines for typical setups:

  • Windows: C:\Python25\Lib\site-packages
  • Linux: /usr/lib/python2.5/site-packages
  • Mac OS X: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages

If you want a definite location, run the following command:

python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

Once you know that location, go there in your command prompt or terminal session. Then execute this command svn co http://code.djangoproject.com/svn/django/trunk/django django. You will see loads of output, showing all of the files that you are downloading as you install Django.

As soon as that process completes, you should run python -c "import django" to make sure everything worked properly. If the command doesn't display an ImportError, you're good. Otherwise, you need to try again.

Getting Access to Django Scripts...

Once you can successfully import django, you might want to make sure you can run the django-admin.py script that comes with Django.

...On Windows

This process is very similar to what we did with the PYTHONPATH environment variable earlier.

  • Open your System Properties again
  • Go to the Advanced tab
  • Click the Environment Variables button
  • Find your PATH environment variable (either for your user or system-wide)
  • Make sure that the variable value contains something like C:\Python25\Lib\site-packages\django\bin
  • Save any changes
  • Open a fresh command prompt
  • Try to run django-admin.py. If you're successful, you're ready to get started with Django. Otherwise, you need to fix your path to django/bin or just call the django-admin.py script using an absolute path when needed.

...On Mac OS X

You can run a command similar to this:

sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/bin/django-admin.py /usr/local/bin

...On Linux

If you have "root" privileges on your Linux system, you can execute a command like:

sudo ln -s /usr/lib/python2.5/site-packages/django/bin/django-admin.py /usr/local/bin

If you don't have "root" privileges, you can setup your own /usr/local/bin:

mkdir ~/bin

Make sure your ~/.bash_rc contains something like:

export PATH=$HOME/bin:$PATH

Then update your current session with any changes you made to ~/.bash_rc by running this command:

source ~/.bash_rc

And that should do it! Now you should be ready to get started with Django.

Feel free to leave a comment if you're having problems installing Django. Good luck!

Check out Installing Django on Shared Hosting.

django-clevercss v0.1

Today I launched another little side project. I call it django-clevercss. Really it's just a simple way to use CleverCSS-formatted stylesheets in Django sites.

At first glance, CleverCSS might not seem like the most useful thing ever, but I personally think it has potential. It is a more concise way to write CSS, and it also allows the use of variables (so you don't have to change 50 of the same hex color codes each time someone wants something a different shade of blue) and simple calculations within the stylesheet. You can also have a sort of "hierarchy" of elements so you don't have to repeat the same element name 30 times for simple styling.

Anyway, since I thought CleverCSS was so clever, I decided that I would make an effort to make the project more accessible for Django developers who agree with me.

This project gives you a way to create CleverCSS stylesheets in your database using the Django administration utility. Then you use a simple template tag to bring the CSS file into your Django templates. Put something like {% get_clever_css "Testing" %} in the href of a regular link tag and that's about it!

Assuming that you have a CleverCSS stylesheet in your database with the title "Testing", the project will do several things. First, it will see if the stylesheet has been parsed and saved to the filesystem. If it has, it will compare the last time the stylesheet on the filesystem was modified with the last modification time of the stylesheet in the database. If the stylesheet in the database is newer than the one on the filesystem, or the stylesheet has not yet been saved to the filesystem, the project will parse the CleverCSS into real, valid CSS and store it in a file on the filesystem. Then you end up with something like this in your template after Django is done with it:

<link rel="stylesheet" type="text/css" media="all" href="/media/clevercss/testing.css" />

For more information and installation instructions, check out the project homepage. Have fun!

Code Koala is now on Django 1.0 Alpha

For the last little while I've been working toward upgrading all of my sites to work with the newforms-admin changes that have been merged into Django's trunk in an effort to release Django 1.0 in a few weeks. However, one of my sites, QuoteBoards.org, was throwing a fit for one reason or another. The fit was enough to stop me from upgrading immediately.

However, I recently got QuoteBoards to a point where I feel it is stable enough on the newforms-admin. I just finished updating everything on my server to Django 1.0 Alpha, and I'm very excited to see what else makes it into the 1.0 final release. If you notice any problems with my site(s), please let me know!

Make Your Own iPod-Compatible Audio Books Using Linux

I like music a lot. I think I always have, and I probably always will. I like to be able to listen to good music wherever I go whenever I want. Thanks to the wonders of technology, we have a myriad of portable media devices to choose from. I personally chose an iPod nano. It's a wonderful little toy.

Anyway, as much as I like music, sometimes I feel that my time could be better used doing things more productive than just listening to music. Once I realized I felt this way, I began looking into ways to get my audio books onto my iPod. At first I simply transfered over the MP3s that came straight from the CDs. But I soon realized that this wasn't the most effective use of the iPod's audio book capabilities. So the hunt was on for some good Windows software to convert my MP3 audio books into M4B format for the iPod.

Now, I'm a pretty cheap guy when it comes to paying for software (which is probably one of the main reasons I started using Linux way back when). I found a bunch of different "free" tools that claimed to be able to convert my MP3's, but few of them actually worked well enough for me to stand using them. Eventually, I found a (very round-about) routine that allowed me to turn everything into something my iPod could understand as an audio book. I followed this routine to convert several audio books and transfer them to my iPod. I never actually finished listening to any of them completely.

Last night I started fooling around with converting my DVDs into a format my iPod could understand. When I finally got The Bourne Identity converted properly, I tried to throw it onto my iPod from my wife's Mac. It told me that I would have to erase everything (because I used my own PC to transfer my files before), and I said it was ok. I didn't have any of my original .m4b files around anymore, and so I began looking for ways of creating those audio books (in Linux this time).

It wasn't long before I stumbled upon a particularly interesting post on this exact topic. It requires the use of mp3wrap, mplayer, and faac. Pretty simple, really. Here's what you do:

# mp3wrap outputfilename *.mp3
# mplayer -vc null -vo null -ao pcm:nowaveheader:fast:file=outputfilename.pcm outputfilename_MP3WRAP.mp3
# faac -R 44100 -B 16 -C 2 -X -w -q 80 --artist "author" --album "title" --title "title" --track "1" --genre "Spoken Word" --year "year" -o outputfilename.m4b outputfilename.pcm

Nice and easy, huh? Now to decipher it all.

# mp3wrap outputfilename *.mp3

This command will stitch a bunch of MP3 files into a single MP3. This makes it easier to have a "real" audio book on your iPod.

# mplayer -vc null -vo null -ao pcm:nowaveheader:fast:file=outputfilename.pcm outputfilename_MP3WRAP.mp3

This command converts that one big MP3 file to PCM (uncompressed) format. Somewhere in the output of this command, you will see something like AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) which comes in handy for the next command:

# faac -R 44100 -B 16 -C 2 -X -w -q 80 --artist "author" --album "title" --title "title" --track "1" --genre "Spoken Word" --year "year" -o outputfilename.m4b outputfilename.pcm

Finally, this command turns the PCM file into an audio book (m4b) file. The 44100, 16, and 2 right after faac all come from that special line in the output of the mplayer command.

As much as I like the command line, I don't like having to remember all of those parameters and options. So I decided to create a utility script (written in Python, of course) to wrap all of these commands into one simple one:

# mp3s2m4b.py BookName mp3s_directory [--quality=0..100] [--artist="artist"] [--album="album"] [--title="title"] [--genre="genre"] [--year=year] [--track=number]

While this might still seem too complex for pleasure, it does reduce a lot of the typing involved with the other three commands. All of the thingies in square brackets (like [--quality=0..100]) are optional. My script runs the commands mentioned previously in order, and suppresses all of the scary output.

I've used my script 4 or 5 different times so far, and it seems to work great. You may download it here.

By George, I Think They've Got it!!

For anyone who's been using Django for any reasonable amount of time, you've probably heard of this thing called the "newforms-admin branch." It's an improved way to interact with the content on your Django website via the built-in Django Administration utility. This particular item has been hot for quite some time--a couple years at least.

These past few weeks have been very exciting for Djangonauts out there. The core developers announced that they would be holding several sprints to bring Django to 1.0 status, which required the completion of the newforms-admin branch. All of this was supposed to be ready by September 2nd.

This morning I decided to do some development while my wife was still asleep. I started by updating several things that I rely upon for my Django sites. Among these was Django itself. Then I noticed that my code wouldn't validate anymore. That's when the excitement began...

I checked the Django website and found this article. It's a public service announcement stating that some backward-incompatible changes were going to be merged into trunk yesterday. Then I checked to see if there were still any tickets stopping the newforms-admin branch from being merged into trunk. None.

So, folks, the official Django newforms-admin is among us. Time to start modifying all of our models and code to play well with the next generation of Django. YAY!

SEO Score: 100%

Yesterday I found out that this website is 100% optimized for search engines to be able to find what they want. I found this by visiting Domain Tools, which can tell you lots of interesting bits of information about your website. Notice the "SEO score" line for this website. I'm not sure that anyone will really be looking for anything on my site, but if they are, I'm ready for them!

New Website!

In case you haven't noticed, this website is a bit different than vcboard.net where all of this content used to be. As stated on the homepage, I am planning on moving all content from vcboard.net over here to codekoala.com, and then putting vcboard.net back to its originally intended purpose. That could take a while.

I am still in the process of moving all data over, but I think I've got most everything that is critical so far. Please be patient with me while I continue transferring data.

openSUSE 11.0: Round 2

Ok, ok... I decided to give openSUSE 11.0 another shot. Since my last blog post, I have read some reviews posted by some other people who encountered similar problems when attempting to actually use KDE4. Some of these people opted to install the KDE 3.5.9 remix after that and had more promising result. So, instead of letting my bias get the best of me, I am going to try openSUSE 11.0 one more time using KDE3. The following are the steps I took while going through this process:

  1. Booted from DVD (openSUSE 11.0 x86_64)

  2. Chose "Installation" from the boot menu

  3. After the installer is completely loaded, I selected "English (US)" for both the language and the keyboard layout, read the license agreement, checked the "I Agree to the License Terms" box, and clicked Next.

  4. I waited for a few seconds while the installer probed my hardware and updated some package lists, then I chose "New Installation" and clicked Next.

  5. The next step was to choose my timezone. They have a very simple interface for this--much less frustrating than the counterpart in the most recent release of Ubuntu (8.04 LTS). My system clock is set to Mountain time, so I left that stuff alone and clicked Next.

  6. This step is probably where I screwed up the most last time. It's where you choose which desktop environment you want. You can choose from GNOME 2.22, KDE 4.0, KDE 3.5, and XFCE Deskop. Last time I chose KDE 4.0. This time I chose KDE 3.5 and clicked Next.

  7. After choosing the desktop environment, the installer took me to the disk partition section of the installation. This should be pretty easy for most people, but I changed a few things. Namely, I put the root and home partitions together, and I deleted one of my Windows partitions because Windows is stupid and bloated. Once I verified the disk partition settings, I clicked Next.

  8. This part is where you get to enter the primary system user's information. You can specify the user's name, login, and password. You may also specify a few options including whether or not the root user will have the same password, whether that user will receive system mail, and whether or not that user will be logged in automatically. If you need to, you may change the authentication settings here too. I just entered the information and got on with it. (If you uncheck the box for the root user having the same password, you're prompted for the root password after this screen)

  9. Finally, we get to the step where you get to verify all of the installation settings. I think I'll just go with the configuration for now. When you click Install, you're prompted to verify that you really want to install. Use your head on this one.

  10. After all of that, it began to format my partitions. One neat thing that I noticed while it was installing was the fact that they rolled commonly-installed packages into what they call "images." This seems to increase installation speed considerably. In the past, I've had most RPM-based distribution installations take as long as (or longer than) Windows takes to install. Granted, the difference there is that you actually get useful stuff once Linux is installed, whereas with Windows, you're stuck with something barely usable and you still have to install drivers for every piece of hardware except your monitor.

    Anyway... the openSUSE folks seem to have addressed that problem recently (maybe just in this release). This went a LOT faster than I've ever seen (on any computer). Despite the use of those images, though, there were still nearly 500 packages that needed to be installed. It seems to be quite evident that the packages are working faster than ever before. It's refreshing (though it did still take quite a bit longer to install than most Debian-based distributions I've tried).

  11. After all of the packages are installed, the system does some configuration and then reboots itself. When it comes back up, the installer will appear, do some more hardware detection and configuration, and then go straight into your desktop.

openSUSE actually didn't detect my 1680x1050 resolution (I didn't know any modern distribution wouldn't anymore), so I just went into YaST and set the resolution to what it should be. And then it locked up, and I had to do a hard reboot. Let's hope I can stop that from happening again. I suppose so long as I can still see things other than my mouse, I should be good.

Upon rebooting into my desktop, the resolution was still crappy. When I went to change it this time, though, I noticed that dual-head mode was enabled. That's stupid. I never plug a second monitor into my laptop. I disabled that, then tried to change the resolution. After logging out and back in, it seems to have changed the resolution properly. While I realize that I do have an extremely crappy video card, Ubuntu and others have been able to offer me 3D acceleration. This option is currently unavailable with openSUSE. Perhaps a little research will solve that problem.

After a few minutes of configuration and preference setting, my system locked up yet again. And another hard reset did the trick of getting it operational again. One more and it's outta here!! I do have to say... Minus the quirks with the resolution and drivers, the distribution does not seem bad at all. It might be worth trying out on a different computer--maybe I'd have better luck.

Alright, now I'm going to check the software management tool for a real driver for my video card. Looks like I may have found some. I hope they work. I'm using a "1-click installer" that I found from a Google search. The installation went fine, but after logging out and back in (to have the drivers take effect), it locked up again.

So, round two folks. Again, it might just be user error. It might just be my computer. Or openSUSE really might just suck. I don't think I'll be trying it on my computer again for a while. I might try on a different system altogether, but not on my main laptop.

First Impressions: openSUSE 11.0

Those of you who have ever held any sort of conversation with me have probably heard or have personal experience with my bigotry concerning Linux. I absolutely love Linux, and I make all sorts of excuses for the things it doesn't to as well as Windows and Mac OS to convince people to use Linux. It's just the way I am.

I've been using Linux as my main operating system ever since about 2000, though I did dabble with it a few times before that. I started out with RedHat Linux way back when, and then moved on to Mandrake (now Mandriva) Linux. As time passed, I found out about this particular distribution called "SuSE Linux," which claimed to be able to detect hardware even better than the others I had tried. It even looked really pretty. I began to really want to use this distribution. It got to the point where I almost spent $80 on it, just so I could play around.

Eventually, I got my hands on a free copy by downloading all of the packages from their FTP server or something. I managed to get this installed, and I was even more impressed than I had anticipated. SuSE Linux was amazing. But by this time, I had already become addicted to downloading and trying out any distribution I could get my hands on. That meant that SuSE spent a few days or weeks on my computer before I replaced it with something else.

As I tried more and more distributions of Linux, I began to form opinions about them. I observed what certain distributions did well, and made hard mental notes about what each distribution didn't do so well. It wasn't long before I noticed that basically all of the RPM-based distributions I had tried suffered from two major problems: bloated installation packages and severe system slow-downs as time went on. It seemed that RPM-based distributions always slowed down just as bad as Windows machines. Other types of Linux, such as Slackware, Gentoo, and Debian, didn't seem to suffer from this nearly as bad.

With these opinions in mind, I carefully chose which distributions I elected to actually install with plans for keeping around a long time. It seemed like I would always download the RPM-based distributions, but I would do it "just in case" someone else wanted the CD or DVD. Sometimes I would download the distributions and never even bother to burn the CD image to disc. I would just stuff the image away for future reference.

However, despite my opinions of RPM-based distributions, I did end up installing SUSE Enterprise Linux Desktop/Server and openSUSE a few years ago. Part of it was for a class I had; another part was to find a distribution that would suit the needs of one of my buddies. I noticed several improvements in the distributions as the years passed, but those lingering problems with bloated packages and system slow-downs still plagued each distribution.

Last week, openSUSE 11.0 was finally released. Just like always, I downloaded the CD and DVD images with no plans of actually installing openSUSE anywhere. As the downloads were going, I read some reviews posted by other people. It sounded like this particular release of openSUSE actually addressed the issues of bloat and system slow-downs (finally!!), so that made me happy, but I still didn't quite consider installing it on any of my computers. I did use one of the live CD's at work for a day, though, and it treated me well.

This morning I got the itch to change the distribution I had installed on my main computer. I was going through the list of recent downloads that I had, and it occurred to me that the most recent version I had was openSUSE 11.0. It also occurred to me that it had been at least two years since I had seriously considered installing openSUSE or SLED/SLES on my computer. So I decided that maybe everything I had read was worth looking into on my own and possibly revisiting my biased opinion of RPM-based distributions.

I started the installation early this morning while I took notes and worked from another machine. The installation went very smoothly. Everything was logical and clean. It really was a good experience. The packages really did seem to install considerably faster than any release in the past, so I had high hopes for how the system would perform after installation. After everything was said and done, my computer rebooted into the freshly installed KDE 4.0 desktop of openSUSE 11.0. It looked nice, and it was actually functional--which I cannot honestly say about any other distributions that have a KDE 4.0 remix.

Since up to this morning I hadn't been able to use KDE 4 long enough to figure out what's changed, that's where I started. I explored the new menu, which I have to admit is quite funky, but I guess that's how the industry likes things nowadays. I played around with some of the personal settings that it offers. Things seemed logical enough, but it is quite a change from KDE 3.5, which I've been using for quite a while.

After a couple minutes of tinkering, I noticed a little bubble in the corner that said something about installing some system updates. I clicked it and ran through some sort of wizard, but I guess there were no updates to install. Or maybe I just have super-slow Internet and it was taking forever to download the changes. Whatever the case, I kept on tinkering with some settings while the updater did its thing.

Next thing I know, my screen goes black and flashes a few times. Then all I can see is a white mouse on a black background. That's it. Nothing else. I'm really not sure what the problem was. The settings I was playing with seemed fairly innocent, as I modify those sorts of settings all the time on KDE 3.5. After a few minutes of white-mouse-on-black-screen fun, I decided a reboot might solve the problem.

A couple minutes later, I was presented with my loading screen, followed by the black screen and white mouse. That's it. Nothing else.

Needless to say, despite all of the improvements that I did notice in this release of openSUSE, it left a rather bitter taste in my mouth in other areas. openSUSE is no longer on my computer--it's long been replaced with yet another distribution.

Maybe it's user error. Maybe it's my computer's hardware. Or maybe openSUSE really does suck. Whatever the case, it wouldn't surprise me if I wait another year or two to try out another RPM-based distribution.

Sad Day for Religious Nerds

I recently decided it would be prudent for me to request permission from the Church of Jesus Christ of Latter-day Saints to redistribute a copy of the scriptures with the PyScriptures program that I have been working on recently. I didn't want to be held liable for any copyright infringement or other legal violations. So I decided to contact them a couple of weeks ago. Here is my message requesting permission:

To whom it may concern:

I would like to request permission to redistribute and use a database which contains the LDS standard works (scriptures only, not the bible dictionary, topical guide, or even footnotes). One of my personal projects relies upon a local copy of the scriptures in order to be useful at all, and I would like people to be able to use this program without fear of any sort of copyright infringement charges to any party. The goal of the program is to offer users of platforms other than Microsoft Windows a way to peruse and study the scriptures without requiring an Internet connection. I have tested it on Windows XP, Linux, and MacOS X and it works great. There are still some parts that need some work, and things could probably be optimized a bit, but works well enough considering that I've only been working on it for about a week and a half.

To learn more about this project, please go to http://code.google.com/p/pyscriptures/ where you can even browse the Python source code for my application (though you might want to do so on an empty stomach). The database is called 'scriptures.db' (http://code.google.com/p/pyscriptures/source/browse/trunk/pyscriptures/scriptures.db) and was created using SQLite in case you are interested in examining and verifying its contents. One of my main reasons for creating this database is that I noticed the database that The Mormon Documentation Project offers is missing some things, particularly all of the answers in Section 77 of the Doctrine and Covenants. I didn't want to find out what else was missing or modified. Perhaps the reason those answers are missing is because that's part of the conditions of redistributing the scriptures?

Please notify me as soon as possible if there are any objections to the use and redistribution of this database. If that is the case, I will delete this project immediately. However, if I may be granted permission to redistribute the database containing the unmodified scriptures, I would greatly appreciate a response which states what my rights are in this matter.

Thank you for your time! Have a wonderful day.

Sincerely,

Josh VanderLinden

Developer

I got my reply today:

Dear Josh VanderLinden:

Thank you for your email dated 9 June 2008 requesting permission to use a database containing the LDS Standard works to redistribute.

After reviewing your request we have determined that we must deny your request for the use of this material. Church policy does not allow its intellectual properties to be used as you are requesting.

We appreciate your intentions, but trust you will understand and support the decision of the Church in this matter.

Thank you for checking with us.

Bobbie Reynolds, Paralegal

Intellectual Property Office

Somehow I could see this coming. I was curious, however, to determine if there was a way I could avoid litigation by modifying the way the program operates. So I responded with this message:

Hello Bobbie,

Thank you for your reply. I'm sorry that the verdict was not in my favor, but I do understand completely. Otherwise, I wouldn't have asked in the first place. Before I remove the project from the Internet, I would like to ask one more question. Is there a way I could somehow make the program legal? I've noticed that other some programs for the scriptures don't exactly redistribute the scriptures with the program itself. Instead they seem to download the scriptures from scriptures.lds.org (or elsewhere?) on an individual level, and the individual who runs the program has to specifically tell the program to do so. Would that be a more appropriate route for my project to take? Or would that also violate the rules?

Thanks again,

Josh VanderLinden

After only a few hours, I received the following reply:

If I understand you correctly, this also sounds like a reformatting project, which is restricted. Thank you for requesting further clarification and for your compliance to Church policy.

Bobbie

So it looks like I will have to discontinue this project, or at least not allow other people to use my work and keep it all to myself. In compliance with the message communicated to me by the legal representatives of the Church, I have removed the project from Google Code, and it shall remain a project for my own purposes. My apologies go out to everyone who actually found this program useful and promising. I can't blame the Church for being strict in its policies--neither should you.