pyspatialite in virtualenv

[pierluigi de rosa-2]

Ciao a tutti,

qualcuno di voi ha mai avuto esperienze nell'installare pyspatialite in un
virtualenv di python?

Stavo lavorando con django ma sono impossibilitato nell'installare la
libreria.
Ottengo il seguente errore:

__main__.HeaderNotFoundException: cannot find proj_api.h, bailing out

Ho letto in rete si dice che manca libproj-dev solo che nel mio caso è
installata.
Altre idee o suggerimenti?
Grazie a tutti
--
Ing. Pierluigi De Rosa (PhD in Earth Science)
Contract Professor of Geographic Information System at University of Perugia
cel: 3497558268 / fax: [phone]
skype: pierluigi.derosa
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[a.furieri]

On Thu, 18 Jan 2018 16:33:54 +0100, pierluigi de rosa wrote:

> Ciao a tutti,
>
> qualcuno di voi ha mai avuto esperienze nell'installare pyspatialite
> in un
> virtualenv di python?
>
> Stavo lavorando con django ma sono impossibilitato nell'installare la
> libreria.
> Ottengo il seguente errore:
>
> __main__.HeaderNotFoundException: cannot find proj_api.h, bailing out
>
> Ho letto in rete si dice che manca libproj-dev solo che nel mio caso
> è
> installata.
> Altre idee o suggerimenti?
>

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

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[Francesco P. Lovergine]

On Thu, Jan 18, 2018 at 05:35:51PM +0100, [hidden email] 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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017

[a.furieri]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017