[Qgis-developer] pyspatialite connector maintenance

a.furieri at lqt.it a.furieri at lqt.it
Mon Jan 10 13:02:07 EST 2011


Hi all developers,

I recently noticed that during the
last month there was an increasing
number of posts into the SpatiaLite's
own mailing list about QGIS / SpatiaLite.
Several users where experiencing some
difficulties when using python plugins:
most notably on Win/OSGeo4W, but on
Ubuntu as well.

During the last days I've performed a
quite thorough debugging, so I'm now 
ready to submit to your attention a 
full report about this topic.
It looks like we have a "broken/missing
link" into the QGIS build/release cycle :-(

=======================================

a) just as a remember: SQLite/SpatiaLite
   aren't client/server, so the same
   library acts in both sql-engine and
   connector roles

b) QGIS directly includes into its base
   code a "private internal copy" of
   sqlite/splite (after all, simply
   two C source are required to implement
   sqlite/spatialite).
   and I personally take care to update
   QGIS each time a new splite's release
   is available.
   so QGIS 1.6 and 1.7-trunk are now 
   supporting the most recent 2.4.0-RC4.

c) but on the Python's side the pyspatialite
   connector still continues using the 
   nowadays obsolete v.2.3.1 (pyspatialite
   as well uses a "private internal copy" of
   sqlite/splite: unhappily, an obsolete one).
   Consequently several issues deriving from 
   mismatching versions arise.
   and apparently nobody is taking care to
   update/synchronize pyspatialite and
   spatialite.

I suppose that all this will sound really
odd and puzzling for end users.
After all, when you have just installed the 
latest QGIS (may be from OSGeo4W) you aren't 
surely expecting to get two mismatching 
versions for the same library to be shipped 
together, one supporting the "main" app,
and the second one supporting python plugins.

So I suppose we are urgently required to
implement some improvement into the QGIS
build/release system, so to grant that
a consistent versioning state is always
ensured.

I'm not at all a CMake guru: and my Python
skills are very superficial.
Anyway I suppose that one of the following
options can surely be implemented:

a) put the pyspatialite sources directly
   into the QGIS build tree, in such a way
   that each time the splite's data provider
   is updated, the same update will surely
   affect the python connector 

b) alternatively (if python own idiosyncrasies
   forbid adopting the above approach),
   inventing something different granting an
   equivalent result.
   But I strongly feel that the pyspatialite 
   maintenance cannot be any longer let in
   an uncontrolled out-of-sync state.

Any useful hint, suggestions and further
considerations from you are surely welcome. 

bye
Sandro

P.S.: here you can get a technical note 
explaining in full detail how-to build 
the pyspatialite connector:
http://www.gaia-gis.it/spatialite-2.4.0-4/splite-python.html




More information about the Qgis-developer mailing list