[Gfoss] Qgis e moduli di python

Ciao a tutti,
ho mandato una mail al gruppo di sviluppo di qgis su una questione che da sempre mi sta a cuore: la ricerca di moduli python e la loro installazione per far funzionare un plugin di python.

Molti utenti nuovi di qgis, si spaventano e abbandonano l’uso dei plugin quando si trovano a dover scaricare un modulo di python…io stesso che ne faccio uso a volte mi scoraggio e rinuncio. Per esempio ancora non posso usare il plugin Omero perchè non c’è pyspatialite installato e non riesco a installarlo.

Quale potrebbe essere una strada buona da seguire per avere i moduli più alla portata di tutti…società civile ma anche popolo, per tornare al vecchio discorso…questo mi pare un buon esempio dell’ostilità all’uso dell’opensource per molti. Su 6 persone che lavorano per me, nemmeno una ha ancora capito dove mettere le mani se gli manca un modulo dopo 3 anni di uso di qgis…

Ciao

Luca

Il 23/06/2011 17.12, Luca Mandolesi ha scritto:

Ciao a tutti,
ho mandato una mail al gruppo di sviluppo di qgis su una questione che
da sempre mi sta a cuore: la ricerca di moduli python e la loro
installazione per far funzionare un plugin di python.

Molti utenti nuovi di qgis, si spaventano e abbandonano l'uso dei plugin
quando si trovano a dover scaricare un modulo di python....io stesso che
ne faccio uso a volte mi scoraggio e rinuncio. Per esempio ancora non
posso usare il plugin Omero perchè non c'è pyspatialite installato e non
riesco a installarlo.

Quale potrebbe essere una strada buona da seguire per avere i moduli più
alla portata di tutti...società civile ma anche popolo, per tornare al
vecchio discorso...questo mi pare un buon esempio dell'ostilità all'uso
dell'opensource per molti. Su 6 persone che lavorano per me, nemmeno una
ha ancora capito dove mettere le mani se gli manca un modulo dopo 3 anni
di uso di qgis....

Hai provato con easy_install?

ciao
Antonio

--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano

Quale potrebbe essere una strada buona da seguire per avere i moduli più
alla portata di tutti…società civile ma anche popolo, per tornare al
vecchio discorso…questo mi pare un buon esempio dell’ostilità all’uso
dell’opensource per molti. Su 6 persone che lavorano per me, nemmeno una
ha ancora capito dove mettere le mani se gli manca un modulo dopo 3 anni
di uso di qgis…

Hai provato con easy_install?

Si ma anche qua il dramma:

host85-247-dynamic:Python-2.5.6 luca$ easY_install pyspatialite
Searching for pyspatialite

unable to execute gcc-4.2: No such file or directory
error: Setup script exited with error: command ‘gcc-4.2’ failed with exit status 1
host85-247-dynamic:Python-2.5.6 luca$

In pratica non ho xcode installato e quindi non posso installare il modulo…ma questo lo so perchè anni fa mi è capitato.

Altre persone che sono solo utilizzatori finali di qgis non sanno manco cosa sia easy_install. I plugin python di qgis (non so se capita anche con quelli di gvSIG in Java) sono un ottimo esempio di di come certe cose nell’opensource siano a metà tra l’utilizzatore finale e lo sviluppatore…e credo che questo tenga molte persone lontane dall’usare questi sw…mentre altri sono stimolati a diventari dei mezzi spatacconi nei programmi come me…

On Thu, Jun 23, 2011 at 05:12:48PM +0200, Luca Mandolesi wrote:

Quale potrebbe essere una strada buona da seguire per avere i moduli più
alla portata di tutti...società civile ma anche popolo, per tornare al
vecchio discorso...questo mi pare un buon esempio dell'ostilità all'uso
dell'opensource per molti. Su 6 persone che lavorano per me, nemmeno una ha
ancora capito dove mettere le mani se gli manca un modulo dopo 3 anni di uso
di qgis....

Mi aggrego anch'io ad esprimere questo "desiderio".
Staro' invecchiando, ma mi scoraggio sempre piu' a dover far
qualcosa di faticoso, anche se solo mentalmente faticoso.

Temo che questo genere di cose pero' si vogliano fare solo
con l'ausilio del sistema operativo, perche' i moduli python
si vorranno installare system-wide (se possibile) e l'utente
che apre qgis NON e' (si spera) amministratore di sistema.

Con gstreamer la cosa si e' "risolta" con la standardizzazione
di una "chiamata di sistema" per l'installazione di plugin.
In questo modo, un'applicazione client (nella mia esperienza: Gnash)
puo' "chiedere" al sistema l'installazione di uno specifico modulo.

Da quel punto in poi l'applicazione non sa cosa succedera', e stara'
quindi al sistema gestire l'altra parte. Se tutto fila liscio,
in una sessione grafica appare tipicamente un popup chiedendo conferma
all' installazione, ed il popup si occupa dell'autorizzazione
all' operazione (root password, sudo password, ...)

Non so se esista uno standard freedesktop o dbus per questo tipo di
comunicazione tra applicazioni e sistema.

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

On Thu, Jun 23, 2011 at 05:33:18PM +0200, Luca Mandolesi wrote:

host85-247-dynamic:Python-2.5.6 luca$ easY_install pyspatialite
Searching for pyspatialite
.......
unable to execute gcc-4.2: No such file or directory
error: Setup script exited with error: command 'gcc-4.2' failed with exit
status 1
host85-247-dynamic:Python-2.5.6 luca$

In pratica non ho xcode installato e quindi non posso installare il
modulo....ma questo lo so perchè anni fa mi è capitato.

In effetti neanche io conosco easy_install, ma un messaggio di quel
genere che nasconde la mancanza di una cosa chiamata 'xcode' per me
e' da segnalare come bug.

Altre persone che sono solo utilizzatori finali di qgis non sanno manco cosa
sia easy_install. I plugin python di qgis (non so se capita anche con quelli
di gvSIG in Java) sono un ottimo esempio di di come certe cose
nell'opensource siano a metà tra l'utilizzatore finale e lo
sviluppatore....e credo che questo tenga molte persone lontane dall'usare
questi sw...mentre altri sono stimolati a diventari dei mezzi spatacconi nei
programmi come me...

Questa duplice funzione dei bug e' molto interessante, sarebbe degno di un
thread a parte. Sto invecchiando. E credo sia colpa dei desktop environment :slight_smile:
Lavorare su una slackware e' stato per me la miglior spinta ad imparare, ma
oggi non ne ho piu' voglia. E' un po' come buttare il bambino in acqua perche'
impari a nuotare. Va bene per i giovani, ma non per chi puo' rompersi una gamba.

Forse si dovrebbero mettere dei bollini sui software: "da 2 a 8 anni" :slight_smile:

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

Ciao Sandro

2011/6/27 Sandro Santilli <strk@keybit.net>:

Temo che questo genere di cose pero' si vogliano fare solo
con l'ausilio del sistema operativo, perche' i moduli python
si vorranno installare system-wide (se possibile) e l'utente
che apre qgis NON e' (si spera) amministratore di sistema.

Un modo ottimo di risolvere questi problemi in Python puo' essere
quello di usare virtualenv [0] che consente di
creare ambienti Python isolati da tutto il resto.
In questo modo l'utente potra':

* creare il suo ambiente Python senza necessita' di essere
amministratore di sistema
* (ma soprattutto) far coesistere piu' ambienti e librerie di Python
distinti, lanciando di volta in volta la combinazione che piu'
interessa

certo, tocca trovare il modo di rendere la creazione di tali
virtualenv a prova di scimmia (comunque e' un'operazione molto semplice)
Straconsigliatissimo! :wink:

ciao
P

[0] http://www.virtualenv.org/

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti

On Mon, Jun 27, 2011 at 04:39:24PM +0200, Paolo Corti wrote:

Ciao Sandro

2011/6/27 Sandro Santilli <strk@keybit.net>:

> Temo che questo genere di cose pero' si vogliano fare solo
> con l'ausilio del sistema operativo, perche' i moduli python
> si vorranno installare system-wide (se possibile) e l'utente
> che apre qgis NON e' (si spera) amministratore di sistema.
>

Un modo ottimo di risolvere questi problemi in Python puo' essere
quello di usare virtualenv [0] che consente di
creare ambienti Python isolati da tutto il resto.

...

[0] http://www.virtualenv.org/

Interessante alternativa. Certo in questo modo dovrebbe essere
piu' semplice, anche se non necessariamente raccomandabile.

L'idea dell'interfaccia standard (il "plugin helper")
consentirebbe l'una o l'altra cosa (o altro ancora), con qualche
tipo di configurazione. La configurazione di quale helper
utilizzare potrebbe essere esposta tramite interfaccia grafica
di qgis (plugin install command, con le keyword substitution).

Come dovrebbe essere questa interfaccia ?
Ne esiste gia' una ? (easy_install)

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

In data lunedì 27 giugno 2011 17:13:57, Sandro Santilli ha scritto:
: > On Mon, Jun 27, 2011 at 04:39:24PM +0200, Paolo Corti wrote:

> Ciao Sandro
>
> 2011/6/27 Sandro Santilli <strk@keybit.net>:
> > Temo che questo genere di cose pero' si vogliano fare solo
> > con l'ausilio del sistema operativo, perche' i moduli python
> > si vorranno installare system-wide (se possibile) e l'utente
> > che apre qgis NON e' (si spera) amministratore di sistema.
>
> Un modo ottimo di risolvere questi problemi in Python puo' essere
> quello di usare virtualenv [0] che consente di
> creare ambienti Python isolati da tutto il resto.

...

> [0] http://www.virtualenv.org/

Interessante alternativa. Certo in questo modo dovrebbe essere
piu' semplice, anche se non necessariamente raccomandabile.

L'idea dell'interfaccia standard (il "plugin helper")
consentirebbe l'una o l'altra cosa (o altro ancora), con qualche
tipo di configurazione. La configurazione di quale helper
utilizzare potrebbe essere esposta tramite interfaccia grafica
di qgis (plugin install command, con le keyword substitution).

Come dovrebbe essere questa interfaccia ?
Ne esiste gia' una ? (easy_install)

mumble mumble... ... ecco qualche pensierino sul tema.

easy_install verrà probabilmente sostituito da "pip"

http://stackoverflow.com/questions/3220404/why-use-pip-over-easy-install

però da quanto ho capito, easy_install viene installato automaticamente con il
pacchetto setuptools, mentre pip lo devi installare a mano (o con
easy_install).

Comunque, questo non è importante, l'importante è capire se (per tutte le
piattaforme), dando per scontato che almeno l'interprete python sia installato
(altrimenti ha poco senso parlare di plugin python), su quali tool possiamo
contare per un'installazione automatizzata delle dipendenze python ?

Purtroppo conosco una sola piattaforma (Linux) quindi non ho idea di come
possa funzionare sulle altre, ma su Linux bisognerebbe installare nell'ordine:

- virtualenv (a livello di sistema, credo)
- easy_install o pip (magari setuptools viene installato di default?)
- le dipendenze del caso

Io credo che un grosso passo avanti sarebbe già quello di includere le
istruzioni "import" in blocchi try/except e stampare un sano messaggio su come
risolvere il problema in caso di dipendenze mancanti, al momento la situazione
è un orribile traceback, veramente disorientante per chi non lo sa leggere.

Per un'installazione automatizzata, si potrebbe pensare ad includere nella
dichiarazione del plugin l'elenco delle dipendenze (in formato
pip/easy_install compatibile) e procedere al caricamento in caso manchino.

C'è anche questo:
http://packages.python.org/distribute/setuptools.html#using-find-packages

... promette bene:

Automatically find/download/install/upgrade dependencies at build time using
the EasyInstall tool, which supports downloading via HTTP, FTP, Subversion,
and SourceForge, and automatically scans web pages linked from PyPI to find
download links. (It’s the closest thing to CPAN currently available for
Python.)

Forse il problema principale è che i plugin al momento vengono semplicemente
scaricati e scompattati, non viene lanciato nessuno script di setup, che
sarebbe fondamentale per qualsiasi installazione di dipendenze.

Vedi lo standard:
http://docs.python.org/install/index.html

Ultimo problemuccio: alcuni pacchetti python contengono pezzi di codice in
altri linguaggi (tipicamente in C), quindi il processo di installazione
standard "python setup.py install" prevede compilazione, che a sua volta
prevede magari che siano già installati gli header e/o altre librerie.

Insomma, un sistema standardizzato per dare utili istruzioni all'utente in
caso di dipendenze mancanti costerebbe poco sforzo e darebbe un grande
risultato, un sistema automatico che funzioni magari nel 60% dei casi sarebbe
già più laborioso, un sistema automatico che funzioni sempre, credo che sia
quasi impossibile.

Altre idee ?

--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502