[Gfoss] [INFO] Re: pyspatialite in virtualenv

a.furieri a lqt.it a.furieri a lqt.it
Ven 19 Gen 2018 15:19:41 CET


On Fri, 19 Jan 2018 11:54:12 +0100, Francesco P. Lovergine wrote:
> 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.
>

caro Frankie,

mi pare che al riguardo ci sia un po' di confusione; sia SQLite
che SpatiaLite si sono evolute nel corso degli anni, ed alcuni
dettagli sono significativamente cambiati con le versioni
piu' recenti.

SQLite a partire dalla versione 3.7.17 (rilasciata nel maggio
2013, quasi cinque anni fa) e' in grado di supportare una
"load_extension" realmente portabile cross-platform.
molte cose che si leggono in giro sono purtroppo basate
sul comportamento di versioni ormai morte e sepolte, che
oggi e' definitivamente superato.

con le versioni recenti di SQLite non c'e' piu' nessun
bisogno di specificare il suffisso .dll o .so o .dylib;
ci pensa automaticamente SQLite ad aggiungere il
suffisso appropriato per la piattaforma di run-time.
decisamente e' un grosso aiuto per scrivere codice
portabile tra piattaforme diverse.
attenzione pero'; tutto questo avviene solo se il nome
del modulo non contiene gia' di suo un suffisso; quindi
utenti e sviluppatori dovrebbero sempre avere l'accortezza
di evitare accuratamente di aggiungere qualsiasi tipo di
suffisso al nome del modulo.

secondo aspetto assulutamente critico che viene spesso
frainteso.
la load_extension() di SQLite e' direttamente basata
sulla dlopen() dei sistemi Posix (compreso Linux),
oppure sull'analoga LoadLibrary() di Windows.
entrambe andranno automaticamente a cercarsi il modulo
da caricare e le relative dipendenze tra le directories
"di piattaforma" abilitate al caricamento delle librerie
dinamiche; ovviamente i dettagli sono diversissimi tra
Linux e Win, ma il succo e' sempre il medesimo.
ne consegue che il modo migliore e piu' facilmente portabile
per caricare l'estensione SpatiaLite e' semplicemente questo:

SELECT load_extension('mod_spatialite');

in questo modo si lascia completamente mano libera a SQLite
di seguire al meglio tutte le regole specifiche della
piattaforma; cioe' il massimo che si possa chiede in termini
di effettiva portabilita' universale.

l'ultima spiaggia dettata da assoluta disperazione: se proprio
insistete SQLite e' anche in grado di caricare un modulo di
estensione identificato tramite un path relativo o assoluto;
ma a questo punto dovrebbe essere ben chiaro a tutti che una
cosa del genere rappresenta un vero e proprio attentato
contro la portabilita'.

purtroppo troppi tra gi utenti e gli sviluppatori ignorano
del tutto persino l'esistenza delle variabili d'ambiente.
l'eseprienza maturata sul campo insegna che molto spesso problemi
apparentemente irresolubili che impediscono il caricamento di
spatialite come estensione dinamica diventano invece banali
semplicemente configurando a modo la variabile LD_LIBRARY_PATH
(su Linux) oppure la PATH (su Win).

conclusione: oggi come oggi non e' piu' giustificato
sostenere che caricare un'estensione dinamica per
SQLite implichi necessariamente ammazzare la portabilita'
universale del codice.
basta solo seguire scrupolosamente le regole della piattaforma
specifica (largamente preferibile), oppure avere quel pizzico
di skill che serve per riconfigurare un ambiente custom nel
caso  (sciagurato, ma praticamente inevitabile su WinZoz) in
cui si preferisca installare i moduli e le loro dipendenze in
qualche posizione "strana".


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

e allore cosa dovrebbe dire chi ormai viaggia sopra ai 60 ? :-P

ciao Sandro



Maggiori informazioni sulla lista Gfoss