Category Archives: Django

Edx on Debian Stretch

After you clone the Edx repo there you will find a (undocumented) list of packages required to install on Ubuntu:

requirements/system/ubuntu/apt-packages.txt

These packages and others are required for Debian Stretch.  First, install these packages:

sudo apt-get install $(grep -vE "^\s*#" requirements/system/ubuntu/apt-packages.txt   | tr "\n" " ")

And then install these packages:

sudo apt-get install python-scipy python-numpy build-essential python-dev gfortran libfreetype6-dev libjpeg-dev libtiff5-dev zlib1g-dev libpng-dev  libxml2-dev libxslt-dev yui-compressor graphviz libgraphviz-dev graphviz-dev mysql-server libmysqlclient-dev libgeos-dev libreadline7 libreadline7-dev mongodb nodejs mysql-client virtualenvwrapper libgeos-ruby1.8 lynx-cur libxmlsec1-dev swig  libsqlclient-dev libxmlsec1

Like the photo? See a bigger version on Flickr.

Migrate Django 1.4 to 1.11

I thought these rough notes might be useful to anyone migrating from Django 1.4 (and possibly 1.3) to Django 1.11.

Moving from South to Django Migrations

1. Update your settings files:

Remove ‘south’ from your INSTALLED_APPS

2. Remove migrations.

Remove all app/migrations files except for __initi__.py . Remove any *.py[c|o] files.

Make sure there’s no migrations specific code in your app/migrations/__init__.py files

https://docs.djangoproject.com/en/1.7/topics/migrations/

3. Run new Migrations

python manage.py makemigrations;

python manage.py migrate;

Moving from Django 1.3/1.4 -> 1.11

This is a 1.3 app migrated to 1.4 and now is being migrated to 1.11.

Will probably need a new manage.py file. Create a dummy project and copy manage.py over your existing manage.py file or diff the two). Rename your settings directory to match the name of your project. In my case the project is portal, settings renamed to portal.

URLS files:

django.conf.urls.defaults is replaced by django.conf.urls

patterns() is gone, see:

https://docs.djangoproject.com/en/1.11/releases/1.8/#django-conf-urls-patterns

Views

django.views.generic.simple

django.views.generic.simple is gone, removed in 1.5.

Replace django.views.generic.simple.direct_to_template with TemplateView:

from django.views.generic import TemplateView

Shortcuts

from django.shortcuts import RequestContext

Replaced with:

from django.template import RequestContext

Contrib

django.contrib.databrowse is gone. See:

Forms

This error:

django.core.exceptions.ImproperlyConfigured: Creating a ModelForm without either the 'fields' attribute or the 'exclude' attribute is prohibited; form BlahForm needs updating.

Change in Django 1.8. See:

Quick fix is:

fields = '__all__'

But you will need to confirm that you want the form to expose all fields.

Formtools

Removal of django.contrib.formtools:

Is now separate package, install with pip:

pip install django-formtools

Change imports from django.contrib.formtools to formtools. For example:

from django.contrib.formtools.preview import FormPreview

Becomes:

from formtools.preview import FormPreview

Models

model._meta.get_all_field_names() is gone.

See:

https://docs.djangoproject.com/en/1.9/ref/models/meta/#migrating-from-the-old-api

This is verbatim from the docs:

MyModel._meta.get_all_field_names() becomes:

from itertools import chain
list(set(chain.from_iterable(
    (field.name, field.attname) if hasattr(field, 'attname') else (field.name,)
    for field in MyModel._meta.get_fields()
    # For complete backwards compatibility, you may want to exclude
    # GenericForeignKey from the results.
    if not (field.many_to_one and field.related_model is None)
)))

This provides a 100% backwards compatible replacement, ensuring that both field names and attribute names ForeignKeys are included, but fields associated with GenericForeignKeys are not. A simpler version would be:

[f.name for f in MyModel._meta.get_fields()]

While this isn’t 100% backwards compatible, it may be sufficient in many situations.

Commands

BaseCommand

BaseCommand.option_list is gone.

See https://docs.djangoproject.com/en/1.11/releases/1.8/#extending-management-command-arguments-through-command-option-list .

Arguments

See here for how to add arguments:

https://docs.djangoproject.com/en/1.11/howto/custom-management-commands/#accepting-optional-arguments

These custom options can be added in the add_arguments() method like this:

class Command(BaseCommand):

    def add_arguments(self, parser):

        # Positional arguments

        parser.add_argument(‘poll_id’, nargs=‘+’, type=int)

        # Named (optional) arguments

        parser.add_argument(

            ‘–delete’,

            action=‘store_true’,

            dest=‘delete’,

            default=False,

            help=‘Delete poll instead of closing it’,

        )

Move from MySQL to Postgres

Bigger or more complex databases may want to do a manual migration where the database is migration using django models.

https://www.calazan.com/migrating-django-app-from-mysql-to-postgresql/

I’ll update this as I have time.

django.db.utils.DataError: invalid value for parameter “TimeZone”

If your Django Apps throws this error:

    cursor.execute(self.ops.set_time_zone_sql(), [tz])

django.db.utils.DataError: invalid value for parameter "TimeZone": "America/New_York"

The problem is that your Database and Django app are set to use different timezones.

Search your Django settings files for this:

TIME_ZONE =

And then connect to your database and query for the timezone. In Postgres run this query:

show timezone;

The fix is to have your Database and Django app use the same time zone. The quickest fix is to set TIME_ZONE in your Django app to be the same as your Database.