Hi again, time for my next GeoDjango-on-SQLite question. In order to load the SpatiaLite extensions for SQLite, you first need to enable SQLite extensions in the first place. Unfortunately, pysqlite did not expose this functionality until pysqlite 2.5.0, which means it didn't make it into Python's sqlite3 module (which is essentially a snapshot of pysqlite 2.3.2, even in Python 2.6 ; I haven't checked Py3k).
The same need arises if you want to use any other SQLite extensions, like the full-text-search extension. So, I'm trying to figure out the cleanest way to let users take advantage of a newer pysqlite2 if it's present, since currently Django always uses sqlite3 if it's there. The original reason for making sqlite3 the default was to "to do the right thing first and fallback" (#2772), which made the (seemingly reasonable) assumption that sqlite3 would become the undisputed correct name in the future. Unfortunately, the package itself retained the pysqlite2 name, and only the Python-internal snapshots (which will inevitably become outdated) have the sqlite3 name. Options include: A. Leave sqlite3 as the default, and add a configuration setting that forces use of pysqlite2 if desired. B. Always try both sqlite3 and pysqlite2, and use whichever has the greater version number if both are present. C. Same as B, but with an optional configuration option to force one or the other if desired. D. Switch to making pysqlite2 the default, since that's the correct name for the module if the user has explicitly installed it, and treat the Python-bundled version as the fallback. E. Develop arbitrarily convoluted bits of logic that pay attention to e.g. what Python version we're running under or the phase of the moon or something. I think I'm personally slightly inclined towards C, but I would be happy with B or D. I don't really like A because I worry that the sqlite3 module will become increasingly outdated and this configuration option will be an extra step and source of confusion for new users. But users would already be forced to think about the issue when installing pysqlite2 in the first place, so A would not be the end of the world either, and it does minimize the chance of accidentally breaking users with partially-broken pysqlite2 installations that Django is currently blissfully ignoring. Thoughts? If there's a consensus on an approach, then I can open a ticket with a patch.... Matt Matt Hancher Intelligent Systems Division NASA Ames Research Center [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
