[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
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
and I personally take care to update
QGIS each time a new splite's release
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
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
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
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.
P.S.: here you can get a technical note
explaining in full detail how-to build
the pyspatialite connector:
More information about the Qgis-developer