Changes between Version 8 and Version 9 of DjangoOnWindows
- Timestamp:
- Jul 29, 2008, 5:51:50 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DjangoOnWindows
v8 v9 5 5 [[TOC]] 6 6 7 == Test suite failures==7 == Development == 8 8 9 As of r7805 the test suite is failing in two places when run on Windows + Python 2.5.2: 9 === Test suite failures === 10 10 11 * If setuptools is installed, on a test from {{{tests/regressiontests/templates/loaders.py}}} related to trying to load a template from an egg. 11 As of r8135 the test suite is showing the follwing platform-specific failures when run on Windows + Python 2.5.2: 12 12 13 * On a test from {{{tests/regressiontests/queries/models.py}}} when using the sqlite3 Django DB backend. 13 14 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 ==== 39 16 40 17 This has been reported as ticket #7570. … … 164 141 As 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. 165 142 166 ==== Possible solution====143 ===== Possible solution ===== 167 144 168 145 As 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). … … 170 147 As 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.) 171 148 172 ==== How does this affect Django====149 ===== How does this affect Django ===== 173 150 174 151 The 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: … … 202 179 Reasoning 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. 203 180 204 == See also==181 == Deployment == 205 182 206 183 * WindowsInstall 184 * wiki:django_apache_and_mod_wsgi 185 * ServerArrangements