Code

Changes between Version 8 and Version 9 of DjangoOnWindows


Ignore:
Timestamp:
07/29/08 03:51:50 (6 years ago)
Author:
ramiro
Comment:

#7767 has been fixed in [8135]

Legend:

Unmodified
Added
Removed
Modified
  • DjangoOnWindows

    v8 v9  
    55[[TOC]] 
    66 
    7 == Test suite failures == 
     7== Development == 
    88 
    9 As of r7805 the test suite is failing in two places when run on Windows + Python 2.5.2: 
     9=== Test suite failures === 
    1010 
    11  * If setuptools is installed, on a test from {{{tests/regressiontests/templates/loaders.py}}} related to trying to load a template from an egg. 
     11As of r8135 the test suite is showing the follwing platform-specific  failures when run on Windows + Python 2.5.2: 
     12 
    1213 * On a test from {{{tests/regressiontests/queries/models.py}}} when using the sqlite3 Django DB backend. 
    1314 
    14 === tests/regressiontests/templates/loaders.py === 
    15  
    16 When setuptools is installed (tested with version 0.6c8), the unittest contained in this file fails. Error is: 
    17  
    18 {{{ 
    19 ====================================================================== 
    20 ERROR: A template can be loaded from an egg 
    21 ---------------------------------------------------------------------- 
    22 Traceback (most recent call last): 
    23   File "C:\ramiro\django-trunk\tests\regressiontests\templates\loaders.py", line 82, in test_existing 
    24     contents, template_name = lts_egg("y.html") 
    25   File "C:\ramiro\django-trunk\django\template\loaders\eggs.py", line 24, in load_template_source 
    26     raise TemplateDoesNotExist, template_name 
    27 TemplateDoesNotExist: y.html 
    28 }}} 
    29  
    30 ==== Solution ==== 
    31  
    32 See ticket #7767. 
    33  
    34 ==== Workaround ==== 
    35  
    36 Uninstall setuptools. On [7751] Adrian modified the test suite machinery to skip the test(s) that depend on setuptools when it isn't installed. 
    37  
    38 === tests/regressiontests/queries/models.py === 
     15==== tests/regressiontests/queries/models.py ==== 
    3916 
    4017This has been reported as ticket #7570. 
     
    164141As it can be seen, the test under Linux were always successful, this may be due to the fact that on these platforms the shared sqlite3 library being used by the pysqlite2 (Python 2.4) or sqlite3 (Python 2.5) Python modules is the system wide one and so it hasn't been frozen at 3.3.4. 
    165142 
    166 ==== Possible solution ==== 
     143===== Possible solution ===== 
    167144 
    168145As the table above shows, version 3.3.4 of sqlite seems to be affected by this bug whilst version 3.3.6 isn't (see http://sqlite.org/changes.html for possible hints). 
     
    170147As sqlite/pysqlite development continues, the pysqlite project keeps publishing new win32 binary installers for Python 2.5. Latest as of June 29, 2008 is version 2.4.1 ({{{pysqlite-2.4.1.win32-py2.5.exe}}}) that uses sqlite version 3.5.2 (see entry marked with '''*''' in the table above.) 
    171148 
    172 ==== How does this affect Django ==== 
     149===== How does this affect Django ===== 
    173150 
    174151The problem doesn't lie within Django itself, but leads to ask oneself if the order being used by the sqlite3 backed to try loading the sqlite DB-API2 modules ({{{django/db/backends/sqlite3/base.py}}}) shouldn't be inverted: Try loading pysqlite2 first and if this fails then try loading sqlite3: 
     
    202179Reasoning behind this is that this would allow the user to take advantage of newer pysqlite2/sqlite3 versions he/she may have installed even if using Python 2.5.x. This might be true and desirable regardless of platform. 
    203180 
    204 == See also == 
     181== Deployment == 
    205182 
    206183 * WindowsInstall 
     184 * wiki:django_apache_and_mod_wsgi 
     185 * ServerArrangements