Topic: Storage parametri applicazione : un consiglio  (Letto 334 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Storage parametri applicazione : un consiglio
« il: Aprile 20, 2019, 12:43 »
Buon giorno a Voi ... e buona Pasqua, data la prossimità :)

Desidererei un consiglio :
nei sistemi unix-like è ampiamente usato memorizzare parametri opzionali di una applicazione scelti da un utente in una direttrice nascosta nella home dell'utente, cosa semplice da realizzare con python

import os
...
def load_app_configurations():
    '''Acquisisce, se esistono, le scelte applicative salvate.'''
    home = os.path.expanduser('~')
    app_dir = os.path.join(home, '.app_name')
    if not os.path.exists(app_dir):
        os.mkdir(app_dir)

mi apprestavo ad utilizzare una tale metodologia ma mi son fermato un attimo, so che "funzionerebbe" anche in windows, almeno per alcune versioni, ma mi chiedo se esiste una qualche convenzione/linea guida in merito, almeno per l'ambito python ...  sapreste darmi suggerimenti in merito?

Offline Markon

  • python sapiens sapiens
  • *
  • moderatore
  • Post: 4.104
  • Punti reputazione: 5
    • Mostra profilo
    • Neolithic
Re:Storage parametri applicazione : un consiglio
« Risposta #1 il: Aprile 20, 2019, 22:05 »
Ciao,

che io sappia non esistono linee guida, se non quelle dettate dal sistema operativo. I file di configurazione tipicamente vanno nella home dell'utente che lancia il programma (sia su Win sia su Linux che su Mac) e spesso e' buona cosa nascondere la directory cosi' da non rendere la directory piena di file di configurazione.

Offline bebo

  • python erectus
  • ***
  • Post: 238
  • Punti reputazione: 0
    • Mostra profilo
    • bebo_sudo's personal homepage
Re:Storage parametri applicazione : un consiglio
« Risposta #2 il: Aprile 21, 2019, 14:42 »
freedesktop.org contiene una "proposta di standard" per Linux: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #3 il: Aprile 22, 2019, 07:40 »
Vi ringrazio delle risposte.

Per lo meno, ho conferma che detto metodo è applicabile nei s.o. più diffusi, anche se "nascondere" lascia il tempo che trova.

Interessante la proposta di standard segnalata da @bebo, sarebbe ora che si adottassero schemi di comportamento unificati, per limitare la confusione nelle home-dir ... già ci pensa l'utente a crearla :)
da una veloce verifica nel mio Ubuntu 18.04, sembrerebbe parzialmente adottata solo da unity per sue specifiche esigenze, da verificare circa i permessi in scrittura

NzP:~$ echo "$XDG_DATA_HOME"

NzP:~$ echo "$XDG_CONFIG_HOME"

NzP:~$ echo "$XDG_CONFIG_DIRS"
/etc/xdg/xdg-unity:/etc/xdg
NzP:~$ echo "$XDG_CACHE_HOME"

NzP:~$ echo "$XDG_RUNTIME_DIR"
/run/user/1000
NzP:~$ ls "$XDG_RUNTIME_DIR"
bus     dconf  gnupg  gvfs-burn  pulse    unity
dbus-1  gdm    gvfs   keyring    systemd  update-notifier.pid
NzP:~$

Comunque, faccenda da tener d'occhio

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #4 il: Aprile 23, 2019, 14:26 »
Su Windows la policy è chiara (magari non seguita, ma...): in %ALLUSERSPROFILE%\\myapp i dati non user-dependent dell'applicazione (se ha senso), in %LOCALAPPDATA%\\myapp (o al massimo in %APPDATA%\\myapp) i dati dell'utente. E più in generale, https://docs.microsoft.com/it-it/windows/desktop/shell/knownfolderid.
Poi per fare questo sarebbe buona educazione fornire anche un installer/uninstaller che pulisce correttamente i vari pezzetti lasciati in giro...
Se però si trattta del solito programmino distribuito alla selvaggia, allora è di gran lunga preferibile usare una sub-directory "interna" all'applicazione e tenere tutto quanto il più vicino possibile senza spargere cose in giro.

In Linux in effetti.... la situazione è più sfumata. Eh.

La parola "nascosta" è ovviamente priva di significato in questo contesto, come è stato detto mille volte. Non puoi nascondere nulla sulla macchina di proprietà di un altro.

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #5 il: Aprile 23, 2019, 18:21 »
Grazie delle info @RicPol

Leggersi il s.o., quindi, poi regolarsi.

...Poi per fare questo sarebbe buona educazione fornire anche un installer/uninstaller che pulisce correttamente i vari pezzetti lasciati in giro...
Se però si trattta del solito programmino distribuito alla selvaggia, allora è di gran lunga preferibile usare una sub-directory "interna" ...
beh, la parte evidenziata rientra tra le "intenzioni" in divenire, anche se argomento che temo metterà a dura prova le mie denutrite meningi, allo stato men che selvagge.
La sub interna alla directory applicativa l'avevo considerata ma in genere non la uso per abitudine, più che altro perché le piccole applicazioni che faccio a mio uso e consumo le porto in giro su chiavetta e le faccio girare su diversi computer, tutti linux ma con caratteristiche differenti, alla lunga ho una preferenza per lo storage sulla macchina in uso ... anche se come motivo non è per nulla buono :)

Grazie, ciao

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #6 il: Aprile 23, 2019, 23:06 »
> Leggersi il s.o., quindi, poi regolarsi.
Oppure usare una roba come questa https://github.com/ActiveState/appdirs ma bisogna leggere il codice per bene e capire se fidarsi.

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #7 il: Luglio 23, 2019, 07:43 »
Riprendo, dopo tanto tempo, questo post ... in particolare, per una riflessione sulla parte "installer/uninstaller" sollevata dal buon @Ric.

Tra i continui inceppamenti che la vita commina, sto continuando a "guardarmi" python, notando differenze funzionali tra versioni "vicine" (tipo 3.5 - 3.6) e, cosa ben peggiore, anche nella stessa versione nello stesso operativo di base.
Mi riferisco, nello specifico, alla distribuzione linux "Ubuntu" vers. 18.04 ove trovo differenze funzionali rilevanti nelle installazione di librerie, tramite pip o altro, tra le versioni basate su gnome/unity ed una basata su KDE che sto cercando di "prepararmi" per utilizzarla off-line dato che per alcuni mesi sarò fuori sede e senza internet disponibile.

Or bene, procedimenti applicati efficacemente su gnome, tipo questo per le wx ma anche nella installazione di pillow per ovviare ad alcuni problemi di PIL, falliscono nella installazione in ambiente KDE.
Intendiamoci, non sto cercando supporto in tal senso, risolverò con calma per fatti miei, ma constatare la differenza funzionale già nella sola installazione delle stesse librerie, nella stessa versione di python sullo stesso s.o. di base, con solo l'interfaccia grafica di differenza mi fa tremare i polsi ... come farei ad affrontare "mari ignoti" tipo l'agitato windows (spesso incompatibile con se stesso) o il nebbiosamente remoto Mac?

Vorreste parlare, in maniera discorsiva, su come si affrontano o quali accorgimenti si adottano per tali problematiche?

Chiaramente, non ho ancora affrontato l'argomento, non lo farò sin quando non sarò un minimo soddisfatto del mio modo di "operare" in python, ho si visto alcune cose ma le mie idee sono nebulose e certamente non si chiariranno sin quando non affronterò sistematicamente il discorso ma, penso, aver preliminarmente indicazioni "pratiche" potrebbe aiutare molto.

Grazie dell'attenzione :)
« Ultima modifica: Luglio 23, 2019, 07:45 da nuzzopippo »

Offline bebo

  • python erectus
  • ***
  • Post: 238
  • Punti reputazione: 0
    • Mostra profilo
    • bebo_sudo's personal homepage
Re:Storage parametri applicazione : un consiglio
« Risposta #8 il: Luglio 24, 2019, 12:41 »
Se vuoi parlare dell'installazione di wxPython, ti direi di aprire una nuova discussione, riportando anche il sistema operativo che usi.

PS: dai un occhio qua: https://www.wxpython.org/pages/downloads/

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #9 il: Luglio 24, 2019, 14:03 »
Se vuoi parlare dell'installazione di wxPython, ti direi di aprire una nuova discussione, riportando anche il sistema operativo che usi.

PS: dai un occhio qua: https://www.wxpython.org/pages/downloads/

Grazie della segnalazione @bebo ma no, non volevo parlare delle wx (comunque, il sistema : kubuntu 18.04 mi sembrava sufficientemente indicato).

Probabilmente non sono stato felice nella mia esposizione, ciò che veramente desta il mio interesse è lo spunto di @RicPol sull'opportunità di fornire adeguate procedure di installazione e disinstallazione per una eventuale applicazione, comparato alla notevole "dinamicità" del linguaggio ed alla diversa efficacia delle procedure relative alla installazione di librerie constatata in ambienti similari.

Le wx, come pillow, erano solo esempio, i procedimenti utilizzati ed efficaci per sistemi con gnome ed unity di Ubuntu 18.04 falliscono su di un sistema con Ubuntu 18.04 con  KDE eppure tutte e tre le macchine sono linux a 64 bit ed adottano python 3.6.8.
Tale circostanza mi impone delle riflessioni in merito a quanto possa essere complesso "distribuire" una propria applicazione se si ipotizza sia destinata a sistemi operativi diversi quando già in similari si trovano difficoltà ad installare una stessa libreria.

Maggiore perplessità mi sorge dall'aver constatato che non può ragionarsi neanche per generiche "versioni" di python, in effetti questo codice
NzP:~$ python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import pathlib
>>> cartella_dati = pathlib.Path(input('  '))
  script
>>> cartella_dati
PosixPath('script')
>>> for data_file in sorted(os.listdir(cartella_dati)):
...     print(data_file)
...
pyt
script
test
>>>

Funzionante con la versione 3.6.7 di python (è di un po' di tempo fa) fallirebbe con la versione 3.5.2 per diversità funzionale della libreria "pathlib", oltre tutto presente solo dalla versione 3.4 di python.

Tutte queste "perplessità" sono riferite all'argomento "installer/uninstaller" già introdotto in precedente post da @RicPol, era nelle premesse e pensavo fosse chiaro, probabilmente non è così, comunque la domanda da me intesa è :

Considerate le perplessità da me esposte, Voi che avete "pratica", come Vi regolate riguardo la distribuzione delle Vostre applicazioni? Quali accorgimenti adottate?

... lo so, la domanda è un po' generica e forse anche OT rispetto al contesto del post, ma non mi interessano "soluzioni", quelle le cercherò quando sarà il momento, bensì linee di pensiero di chi ha esperienza in merito, linee che possano evitarmi di intraprendere vicoli ciechi nei miei "tentativi".

Ciao :)

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #10 il: Luglio 24, 2019, 21:44 »
> .... fallirebbe con la versione 3.5.2 ...

Eh beh sì, ma che c'entra. Se usi una feature presente solo dalla versione X, allora il tuo programma funziona solo con python X o superiore. Ma questo vale per qualsiasi cosa, è scontato.

> ...la domanda è un po' generica ...

La domanda è mostruosamente generica. Dipende dal sistema operativo, dal tipo di programma, dal tipo di utente finale che lo deve utilizzare, dalla modalità di distribuzione che hai in mente.
Per esempio, è standard su linux installare progammi con un packet manager: allora per esempio potresti cercarti le guidelines per pubblicare il tuo programma in modo che sia installabile con il packet manager che hai in mente. Se segui la guideline, in teoria stai già facendo la cosa giusta.
Ma in generale il consiglio è: cercati un programma simile al tuo, e vedi come si regola quello... poi copia con giudizio.

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #11 il: Luglio 25, 2019, 08:10 »
> .... fallirebbe con la versione 3.5.2 ...
Eh beh sì, ma che c'entra. Se usi una feature presente solo dalla ...
La domanda è mostruosamente generica. Dipende dal sistema operativo, dal tipo di programma, dal ...

È esattamente l'argomento :D

Speravo, data la tendenza "multi-sistema" del linguaggio (e lo sterminato numero di librerie) potesse essere stato sviluppato un "qualcosa" che permettesse una astrazione rispetto al sistema operativo ... giusto per esemplificare, qualcosa tipo i jar di java, che permettono di incamerare in se le librerie "extra" utilizzate e funzionano indipendentemente dal s.o. su cui risiede la jvm, tecnica che ho utilizzato diffusamente sviluppando in linux con openjdk e poi utilizzando direttamente i jar su windows e mac.

Mi rendo conto che, essendoci il C alla base di python, tale speranza è "molto" campata in aria, essendo il linguaggio molto più legato al sistema su cui risiede di java.

Strategia semplice quindi :
O applicazioni estremamente specifiche per il s.o. di destinazione, oppure applicazioni che utilizzino solo librerie "consolidate" che facciano parte esclusivamente della distribuzione "standard" (che oltretutto rimane mooolto dinamica).

... mi spiace un po' la cosa, essendo il mio "target" al più limitato agli script od alle applicazioni desktop, tkinter non mi piace molto ma se mai vorrò "distribuire" qualcosa mi toccherà quello, temo.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #12 il: Luglio 25, 2019, 19:49 »
Guarda, abbi pazienza non sono sicuro di capire quello che dici...

Python è già "multi-sistema", e permette già di sviluppare in modo astratto dal sistema operativo. Ma ovviamente se usi una feature del linguaggio che è stata introdotta solo di recente, questo ti limita alle versioni più recenti del linguaggio. Oppure, se vuoi (attraverso il linguaggio) usare feature che sono disponibili solo su un certo sistema operativo, questo ti limita a quel sistema operativo.
Ma questo ce lo avresti in java, in haskell, in perl, ce l'avresti con qualsiasi linguaggio. Per dire, se scrivi un programma in java che usa l'http client interno di java, allora ti stai limitando solo alle versioni più recenti dell'sdk, perché prima l'http client interno non c'era. Se vuoi scrivere un software che fa uso di schermi a colori, non puoi sperare che funzioni bene su schermi in bianco e nero. Eh, già.

> essendoci il C alla base di python, tale speranza è "molto" campata in aria, essendo il linguaggio molto più legato al sistema su cui risiede di java.

Adesso questo forse ti sorprenderà, ma guarda che java è scritto in c.
« Ultima modifica: Luglio 25, 2019, 20:59 da RicPol »

Offline nuzzopippo

  • python habilis
  • **
  • Post: 60
  • Punti reputazione: 0
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #13 il: Luglio 26, 2019, 08:30 »
Guarda, abbi pazienza non sono sicuro di capire quello che dici...

Python è già "multi-sistema", e permette già di sviluppare in modo astratto dal sistema operativo...
Il "non capire" spesso riviene da un "non saper spiegare" precedente ed a volte da differenze prospettiche : ampi sguardi travalicano senza notarli gli asfittici orizzonti di visioni limitate (come la mia).
Premesso questo, lo sviluppo applicativo è multi-sistema? : certamente, non ho grossi dubbi in proposito ma si parlava di processi di installazione/disinstallazione

 ... supposto io realizzi una applicazione utilizzante delle librerie al di fuori di quelle fornite di default con python, un processo di installazione non dovrebbe forse prevedere la verifica della disponibilità, od anche l'istallazione, di tali librerie? Un processo di disinstallazione non dovrebbe prevederne la rimozione se non più utili?
Si entrerebbe, allora, in processi specifici per la destinazione finale e si, nel caso linux di impostazione dei "pacchetti" secondo le specifiche relative non solo alla distribuzione ma anche dell'eventuale ambiente di utilizzo.

Ora, uno scarso come me forse ci arriva a fare un "pacchetto" specifico ma cosa dovrebbe fare per un "qualcosa" destinato ad essere utilizzato in vari ambienti? e, poi, questo qualcosa, varrebbe lo sforzo necessario? ... mi sembra ovvio che, in tal caso mi dovrei limitare ad utilizzare, nella codifica, solo le disponibilità standard cercando anche di utilizzare elementi quanto più "stabili" possibili, per evitare il più possibile problemi.

Spero, con questo, di aver chiarito l'ottica da cui sono giunte le mie "scritte", la motivazione delle mie "perplessità", sono un "cosa faccio e mi devo guardare per ..." le motivazioni.

Sono consapevole di ciò che segue la Tua citazione, non mi sorprende, così come non mi sorprende
> essendoci il C alla base di python, tale speranza è "molto" campata in aria, essendo il linguaggio molto più legato al sistema su cui risiede di java.
Adesso questo forse ti sorprenderà, ma guarda che java è scritto in c.
È scritto nella introduzione di tutti i libri su java che ho acquistato (ho il vizio di leggere) ma, ne converrai, una libreria scritta in java per la jvm è profondamente diversa una libreria scritta in C, anche se è scritto in C ciò che la interpreta.

Per altro, ci tengo a precisarlo, queste mie perplessità e/o riflessioni non hanno alcuna mira critica verso il mondo python, esso è quello che è, sto cercando di capirlo e "domando" per ridurre la fatica che ciò mi costa.

Grazie per le Tue risposte :)

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Storage parametri applicazione : un consiglio
« Risposta #14 il: Luglio 26, 2019, 09:25 »
> ma si parlava di processi di installazione/disinstallazione

tranne che invece poi eri passato a lamentarti di pathlib che c'è solo negli ultimi python.

Forse dovresti focalizzare la tua attenzione su quello che decidi essere il tuo problema attuale.
In ogni caso, di base non fa differenza: che si parli di feature platform-dependent o di processi di installazione (che sono anch'essi platform-dependent), la morale è esattamente identica: non puoi pensare che Python (ma neppure Java, se è per questo) ti sollevi dalla responsabilità di conoscere ciò che sta intorno al tuo programma scritto in Python. Ovviamente un linguaggio di alto livello ti offre qualche astrazione in più, ed è anche per questo che si usa. Ma oltre a un certo punto, devi sapere quello che fai.
Se cerchi di accedere (per dire) al file system da un programma Python (o Java), non è che Python (o Java) crei per te un file system nuovo di zecca, sempre uguale su tutte le piattaforme: avrai diversità di comportamento ineliminabili... magari nove su dieci non ci sbatti contro e non te ne accorgi, ma devi sapere che ci sono. Allo stesso modo, se vuoi installare il tuo programma, non è che Python (o Java) crei per te un "protocollo universale" di installazione valido su tutte le piattaforme. Devi sapere dove vuoi atterrare, in linea di massima.

> mi dovrei limitare ad utilizzare, nella codifica, solo le disponibilità standard

assolutamente no, ci mancherebbe. Devi, e puoi, fare esattamente tutto quello che vuoi. L'importante è che tu capisca che cosa stai facendo, e sappia farti una bilancia dei pro e dei contro.
E' un po' come sviluppare un frontend web. Certamente tu puoi limitarti solo al minimo comun denominatore di css e javascript in modo che tutto funzioni anche su Internet Explorer 6, se vuoi. In pratica però tutti gli sviluppatori oggi targettizzano solo le versioni più recenti di Chrome/FF/Edge, e di IE6 se ne fregano. L'importante è capire e decidere.

>  un processo di installazione non dovrebbe forse prevedere la verifica della disponibilità, od anche l'istallazione, di tali librerie?

sì e infatti ci sono vari meccanismi per stabilire la catena dei requirements (e anche vari problemi legati a questi meccanismi... ma così è la vita)

> non dovrebbe prevederne la rimozione se non più utili?

no

>  cosa dovrebbe fare per un "qualcosa" destinato ad essere utilizzato in vari ambienti?

"leggere i dannati manuali", come si diceva una volta. Non c'è un sostituto valido per questo. Informati sulle specifiche dei vari shop, vedi come fanno gli altri, eccetera.

>  questo qualcosa, varrebbe lo sforzo necessario?

E che ne so? Ma perché, invece di stopparti a pensare in astratto, non provi concretamente a sviluppare un pacchetto e pubblicarlo su varie piattaforme? Così vedi quali sono le difficoltà pratiche, fai i tuoi errori, li correggi, valuti i pro e i contro su un caso concreto.

> È scritto nella introduzione di tutti i libri su java che ho acquistato

proprio così, giusto. E quindi? Quale sarebbe la differenza concreta che riscontri con Python? Perché non sono mica riuscito a capirla.

Prova così: fai un esempio concreto di una cosa che in Java sei riuscito a fare ma che in Python non riesci, posta il codice concreto che ti ha permesso di risolvere il problema, e vediamo qual è il problema concreto.