python 3.6 spatialite 4.3 on macOS High Sierra

[Randy Horner]

Has anyone been able read/write to a spatialite database using python 3.6 on a MAC?  Tried sqlite3 but cannot load the spatialite extension without recompiling sqlite3 and I could not get that to compile without errors.  

Was able to read spatialite database with OGR but could not get  to the geometry except when using ExecuteSQL but sql update statement would not work.  

[Kyle Felipe Vieira Roberto]

I had some issues using python on miniconda environment....
using system's python it works fine for me..
im using Debian Stretch...

[Randy Horner]

Thanks for the reply Kyle.   From my understanding I need to build libsqlite3.a to allow loading of extensions (I was able to do this) and then build a new python linking to the new library.  (Failed at this). Well beyond my scope.   Surprised getting this to run on MAC is so difficult, unless I am missing something.  Going to have to dump spatialite and go back to PostGIS.

[a.fu...@lqt.it]

On Tue, 31 Jul 2018 06:12:47 -0700 (PDT), Randy Horner wrote:
> Thanks for the reply Kyle.   From my understanding I need to build
> libsqlite3.a to allow loading of extensions (I was able to do this)
> and then build a new python linking to the new library.  (Failed at
> this). Well beyond my scope.   Surprised getting this to run on MAC
> is so difficult, unless I am missing something.  Going to have to
> dump spatialite and go back to PostGIS.
>

Hi Randy,

SQLite is very simple, but can be compiled and built by applying
many different configuration options; you can find the complete
list here [1].

the vast majority of such options have obscure and rather esoteric
effects, but two of them are absolutely critical for SpatiaLite:
- SQLITE_OMIT_LOAD_EXTENSION
- SQLITE_ENABLE_RTREE

once that the SQLite library is built at compile time by keeping
disabled the capability to dynamically load external extensions
and to support an R*Tree spatial index, it will be completely
useless for SpatiaLite, and there is absolutely nothing you can
do for circumventing such limitation simply because many relevant
portions of code have been permanently removed from the executable
binary.

it's a very long time (many years) that I've definitively abandoned
the MAC family, mainly because of its stupid decision to ship a badly
gelded and practically useless system SQLite strictly requiring to be
duly replaced by a more reasonable custom built alternative.
AFAIK Mac Os X is the unique and only operating system adopting such
an idiotic and frustrating system policy.

technical note: I strongly doubt that using the static library
(libsqlite3.a) could be the best way to rebuild Python; the
dynamic library (libsqlite3.dylib) seems to be a more probable
candidate.

hint: there are at least two open source distributions intended
to circumvent the too many oddities of Mac Os X:
- HomeBrew [2]
- MacPorts [3]
the one and/or the other will be presumably able to install
on your Mac more standard versions of both libsqlite3 and
python.

bye Sandro

[1] https://www.sqlite.org/compile.html
[2] https://brew.sh
[3] https://www.macports.org

[Randy Horner]

Thanks so much for you reply Sandro.  (And all the help you give everyone)   I'll take a look at macports and brew before I move on to postgis.

PS. I would dump my MAC in a second for all the reasons you list, but alas, it is for work and I have no choice.