= Django on Windows =

(work in progress)

== Test suite failures ==

As of r7787 the test suite is failing in two places when run under Windows:

 * If setuptools is installed, on a test from {{{tests/regressiontests/templates/loaders.py}}} related to trying to load a template from an egg (from a report on #django-dev, this is a test that is also failing under OS X).
 * On a date-related query from ({{{tests/regressiontests/queries/models.py}}}) when using the sqlite3 Django DB backend under Pyhton 2.5.2

=== tests/regressiontests/templates/loaders.py ===

TBD

=== tests/regressiontests/queries/models.py ===

This test:

{{{
#!python
Bug #7087 -- dates with extra select columns
>>> Item.objects.dates('created', 'day').extra(select={'a': 1})
[datetime.datetime(2007, 12, 19, 0, 0), datetime.datetime(2007, 12, 20, 0, 0)] 
}}}

from {{{tests/regressiontests/queries/models.py}}} fails.

This is a minimal models.py that shows the problem (extracted from the above regression test):

{{{
#!python
"""
>>> time1 = datetime.datetime(2007, 12, 19, 22, 25, 0)
>>> time2 = datetime.datetime(2007, 12, 19, 21, 0, 0)
>>> time3 = datetime.datetime(2007, 12, 20, 22, 25, 0)
>>> time4 = datetime.datetime(2007, 12, 20, 21, 0, 0)
>>> i1 = Item(name='one', created=time1, modified=time1)
>>> i1.save()
>>> i2 = Item(name='two', created=time2)
>>> i2.save()
>>> i3 = Item(name='three', created=time3)
>>> i3.save()
>>> i4 = Item(name='four', created=time4)
>>> i4.save()

>>> Item.objects.dates('created', 'day').extra(select={'a': 1})
[datetime.datetime(2007, 12, 19, 0, 0), datetime.datetime(2007, 12, 20, 0, 0)]

"""

from django.db import models
import datetime

class Item(models.Model):
    name = models.CharField(max_length=10)
    created = models.DateTimeField()
    modified = models.DateTimeField(blank=True, null=True)

    class Meta:
        ordering = ['name']

    def __unicode__(self):
        return self.name
}}}



The SQL being generated by Django is correct:

{{{
#!python
>>> Item.objects.dates('created', 'day').extra(select={'a': 1}).query.as_sql()
('SELECT DISTINCT (1) AS "a", django_date_trunc("day", "sqlite3_dates_item"."created") FROM "sqlite3_dates_item" ORDER BY 1 ASC', ())
}}}

Problems seems to be related to some bug in the version of pysqlite2 or sqlite3 (most likely suspect) included with the official Python 2.5.2 win32 installer (2.3.2 and 3.3.4 respectively):

{{{
#!python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from sqlite3 import dbapi2
>>> print dbapi2.version_info
(2, 3, 2)
>>> print dbapi2.sqlite_version_info
(3, 3, 4)
}}}

The same test works flawlessly under the following platforms:
 * GNU/Debian Linux 4.0 (Python 2.4.4 + pysqlite2 2.3.2 + sqlite3 3.3.8)
 * GNU/Debian Linux Sid as of Jun 29, 2008 (Python 2.5.2 + builtin pysqlite2 aka sqlite3 2.3.2 + sqlite 3.5.9)
this may be thanks to the fact that on these platforms the shared sqlite3 library being used by the Python pysqlite2 (Python 2.4) or sqlite3 (Python 2.5) modules is the system wide one and so it hasn't been frozen on 3.3.4.

==== Possible solution ====

The pysqlite project keeps publishing win32 binary installer for Python 2.5.

TBD

== See also ==

 * WindowsInstall