[Gfoss] [INFO] Re: pyspatialite in virtualenv

[Francesco P. Lovergine]

On Thu, Jan 18, 2018 at 05:35:51PM +0100, a.furieri a lqt.it wrote:
>ciao Pierluigi,
>
>io a proposito di pyspatialite posso dirti un'unica cosa; che il suo
>stesso ideatore, sviluppatore e maintainer (Lokkju Brennr aka Loki)
>e' convinto che oggi come oggi non andrebbe piu' usata.
>
>se hai la pazienza di leggerti tutti i dettagli (e per scoprire quali
>sono le possibili alternative), trovi tutto in questo post sulla ML
>di spatialite:
>
>https://groups.google.com/forum/#!topic/spatialite-users/o0jUwMUqx_g
>

Condivido l'inutilità di una replica del binding di sqlite3 per Python
come tutti gli altri linguaggi. In questo periodo per motivi lavorativi
uso più Perl di Python e per i medesimi motivi faccio brutalmente 
qualcosa tipo:

------
	# load Spatialite extension
  	$dbh->sqlite_enable_load_extension(1);
	# this extension load instruction is platform specific...
	my $sth = $dbh->prepare(qq/SELECT load_extension('libspatialite.so')/);
	eval { $sth->execute; };
	if ($@) {
		# in version 4.3 extension changed name
		$sth = $dbh->prepare(qq/SELECT load_extension('mod_spatialite')/);
		$sth->execute;
	}
------

che però evidenzia la bruttezza intrinseca della cosa: caricare una shared library
è qualcosa di platform specific a causa del fatto che load_extension() è una funzione
che non cerca proprio di nascondere certi dettagli. Se invece si usasse un registry
in modo che load_estension() caricasse una capability (per es. SPATIALITE) che
venisse registrata al loading di Sqlite andando a ravanare nella giusta directory, i giusti 
filename (di piattaforma) ecc., si eviterebbe una pletora di tentativi di caricamento 
della benedetta estensione. In definitiva bisognerebbe patchare in tal senso Sqlite
prima di preoccuparsi di tutto ciò in Spatialite e dei suoi binding. 

Va beh, sto troppo pigro per scassare gli zebedei upstream, sono i 50 anni...


-- 
Francesco P. Lovergine