Configurer une application

Bonjour!

Je continue à apprendre Python en m'amusant avec Mandelbrot, et j'ajoute petit à petit des fonctionnalités à ma petite appli de calcul de ce bel ensemble.
J'en suis à proposer de sauver les images calculées sous forme de fichiers jpeg et aussi de sauver dans un fichier XML les paramètres d'une image pour pouvoir la recalculer plus tard si besoin.

Je me retrouve donc à sauver des fichiers, et en conséquence à demander à l'utilisateur de choisir des répertoires. J'y arrive sans problème (et avec votre aide parfois). Mais ce choix est à renouveler à chaque fois que l'appli est lancée, et j'aimerais pouvoir sauver les choix de l'utilisateur d'une façon ou d'une autre.

Je ne vois qu'une seule solution, celle de passer par un fichier de configuration dans lequel ces choix seraient inscrits et qui serait chargé au démarrage de l'application. Mais je n'ai qu'une vision partielle de ce que peut faire Python et surtout, venant du développement web, je n'ai jamais eu trop à me soucier de ce genre de problématique.

Python pourrait-il, par exemple, modifier le fichier point py qu'il est en train d'exécuter pour y inscrire "en dur" les répertoires choisis? Voyez-vous d'autres solutions qui ne passeraient pas par un fichier de configuration?

Merci d'avance!

Bonjour.

Dans mon équipe de développeurs, nous avons pour habitude de gérer ce genre de choses dans des fichiers YAML ou JSON. Tout ce qui est variables jamais modifiées va dans un fichier de variables d'environnement.

On a une classe Config par exemple qui se charge de récupérer ces valeurs + une classe genre ConfigUpdate pour mettre à jour le fichier YAML|JSON si besoin.

Citation:

---

Envoyé par ryan

Python pourrait-il, par exemple, modifier le fichier point py qu'il est en train d'exécuter pour y inscrire "en dur" les répertoires choisis? Voyez-vous d'autres solutions qui ne passeraient pas par un fichier de configuration?

---

Pourquoi voulez-vous faire abstraction d'un fichier de configuration ? Une contrainte particulière dans votre projet qui vous en empêche ou juste que vous ne savez pas (encore) comment vous y prendre ?

Bonjour Arioch, et merci d'avoir pris le temps de me répondre.

Je ne devrais pas avoir trop de problème pour sauver deux noms de répertoires dans un fichier de configuration.

Je me demandais seulement si cette solution est la seule qui puisse être envisagée et si cela valait la peine de me casser la tête à essayer de faire en sorte qu'un fichier point py puisse s'auto-modifier. Cela me semble un petit défi amusant (je suis un jeune retraité, j'ai du temps :D), mais si c'est perdu d'avance, il est inutile que je m'acharne et je pars tout de suite sur un ficher de configuration.

Salut,

Citation:

---

Envoyé par ryan

et si cela valait la peine de me casser la tête à essayer de faire en sorte qu'un fichier point py puisse s'auto-modifier. Cela me semble un petit défi amusant

---

Quand on programme on veille à séparer le code des données.
Et les données sont un vaste sujet.

Intuitivement, la donnée saisie par l'utilisateur (ou la constante déclarée dans le script) ont une durée de vie limitée à l'exécution du programme (le programme terminé, elles ont disparues et il faudra les réinitialiser ou les ressaisir).

Celles qui survivent (que le programme pourra retrouver) seront dites "persistantes".

Et la façon le plus simple pour réaliser cette persistance reste le fichier disque.
Maintenant, on pourrait vouloir des données dont la durée de vie soit la session utilisateur, les reboot de la machine, ... et trouver des endroits plus "propices" pour le réaliser.

- W

Re!

Bon, je vois que cette idée semble saugrenue et contraire aux bonnes pratiques (mais dont je ne suis plus vraiment obligé de me soucier, dilettante que je suis devenu)
et je vais donc partir sur un fichier de configuration.

Du coup, pour s'adapter aux différentes machines et aux différents OS, a-t-on d'autre choix que de placer le fichier de configuration dans le même répertoire que le fichier point py?

Citation:

---

Envoyé par ryan

a-t-on d'autre choix que de placer le fichier de configuration dans le même répertoire que le fichier point py?

---

C'est un fichier de configuration qui dépend de l'utilisateur... donc il serait normal de le mettre dans un répertoire (à lui) de son home directory.

Dans le répertoire du script, on va y poser des "constantes" (des images, des fichiers de configuration par défaut,...) indépendantes de l'utilisateur (ou partagés par tous les utilisateurs).

- W

Citation:

---

Envoyé par wiztricks

C'est un fichier de configuration qui dépend de l'utilisateur... donc il serait normal de le mettre dans un répertoire (à lui) de son home directory.

---

Si l'utilisateur peut placer le fichier de configuration où bon lui semble, comment fait l'application pour le trouver, ce fichier?

Citation:

---

Envoyé par ryan

Si l'utilisateur peut placer le fichier de configuration où bon lui semble, comment fait l'application pour le trouver, ce fichier?

---

Si c'est le cas, ce n'est pas un fichier de configuration spécifique à l'application mais un fichier dont l'utilisateur fait un peu ce qu'il veut.
Côté application, on pourra juste signaler l’absence du fichier et éventuellement demander la confirmation d'un démarrage par défaut... ou avoir une variable du SHELL à mettre à jour en fonction de l'emplacement.

- W

@wiztricks

J'ai un peu de mal à vous suivre...Le fichier où je voudrais sauver les deux noms de répertoires me semble bien être propre à l'application puisqu'il ne sert qu'à l'application. Ou alors nous n'avons pas la même notion de ce qui est propre à une application. Sans ce fichier et les données qu'il contient, un bon nombre de fonctionnalités de l'application ne vont simplement pas fonctionner, même si le reste de l'application ne va pas planter pour autant. Serait-ce là que se trouve la nuance?

Le but de ce fichier est de dispenser l'utilisateur de préciser à chaque fois les deux répertoires de sauvegarde, mais s'il doit préciser un chemin pour trouver le fichier, on n'est pas plus avancé :(

Citation:

---

Envoyé par ryan

Le but de ce fichier est de dispenser l'utilisateur de préciser à chaque fois les deux répertoires de sauvegarde, mais s'il doit préciser un chemin pour trouver le fichier, on n'est pas plus avancé :(

---

Et si vous avez plusieurs utilisateurs comment distinguer les préférences de chacun? Pire, si tous les utilisateurs peuvent écrire dans le dit fichier, un petit malin pourra l'éditer et mettre n'importe quoi.

Dans votre répertoire utilisateur, plein d'applications y sauvegardent des données de configuration... amusez vous à renommer fichiers ou répertoires concernés et regardez ce que fait l'application.

- W

Bonjour

Personnellement, j'utilise la librairie "configparser" pour gérer les configurations de mes applications. Cette librairie est dédiée à gérer les fichiers de type ".ini" qui ont une syntaxe bien définie, exemple

Code:

---

1 2 3 4 5 6 7 8 9

[chapitreA] var1=valeur var2=valeur var3=valeur   [chapitreB] var1=valeur var2=valeur var3=valeur

---

Cette librairie possède des méthodes permettant de récupérer les chapitres et les variables associées, et aussi de les réenregistrer ensuite. Et, conformément aux conventions implicites, pour toutes mes applications, qui ont toutes un nom spécifique (ex appliX), sous windows je nomme le fichier "appliX.ini" et je le nomme ".appliXrc" sous Linux.

Citation:

---

Envoyé par ryan

J'ai un peu de mal à vous suivre...Le fichier où je voudrais sauver les deux noms de répertoires me semble bien être propre à l'application puisqu'il ne sert qu'à l'application.

---

Il est propre à la fois à l'application (deux applications différentes auront deux fichiers différents) mais aussi propre à l'user qui le lance (les préférences de l'user A ne sont pas forcément les mêmes que celles de l'user B)

Donc sous Unix/Linux ton application X sauvegardera la configuration de l'utilisateur A dans le dossier "/home/userA/.applicationXrc" et celle de l'utilisateur B dans le dossier "/home/userB/.applicationXrc". Ces répertoires étant dédiés aux utilisateurs précis, la configuration de l'user A n'impactera pas celle de l'user B et inversement.

Et sous Windows, l'application X sauvegardera dans "C:\Documents and Settings\userA\applicationX.ini" pour le user A et dans "C:\Documents and Settings\userB\applicationX.ini" pour le user B. Suffit de checker os.name pour savoir si on est sous Unix (os.name == "posix") ou Windows (os.name == "nt") ; et récupérer os.path.expanduser("~") pour récupérer (dans tous les OS) le home de l'user qui lance le programme.

@ Sve@r

Merci pour ce topo complet sur la question, il répond à toutes mes interrogations au sujet de la configuration d'une appli avec python.

Bonjour,

Citation:

---

Envoyé par Sve@r

Donc sous Unix/Linux ton application X sauvegardera la configuration de l'utilisateur A dans le dossier "/home/userA/.applicationXrc" et celle de l'utilisateur B dans le dossier "/home/userB/.applicationXrc". Ces répertoires étant dédiés aux utilisateurs précis, la configuration de l'user A n'impactera pas celle de l'user B et inversement.

---

N'est-il pas préférable de mettre le fichier dans le dossier ~/.config ?

Citation:

---

Envoyé par Hominidé

N'est-il pas préférable de mettre le fichier dans le dossier ~/.config ?

---

Sais pô... gvim travaille avec ~/.vimrc (ou ~/.exrc), XSession travaille avec ~/.xsessionrc, pylint travaille avec ~/.pylintrc et évidemment bash avec ~/.bashrc !!!
Ensuite oui vlc travaillle avec ~/.config/vlc, QGis travaille avec ~/.config/QGis, designer travaille avec ~/.config/Trolltech bref il y a donc du oui et du non donc je ne sais pas trop quoi donner comme avis. Il "semblerait" que .config soit plus destiné à contenir des dossiers de configuration et non pas de simples fichiers...
Maintenant (pour mon cas perso), travailler directement depuis le HOME me permet de simplifier la gestion Linux/Windows (os.path.expanduser("~") dans les deux cas, sans avoir besoin de rajouter ".config" dans le cas Linux). Et puis imagine que mon appli soit utlisée chez un user moldu dans lequel ".config" n'existe pas..:zen:

Citation:

---

Envoyé par Sve@r

Sais pô...

---

d'après le document https://specifications.freedesktop.o...ec-latest.html, la convention est:

Citation:

---

$XDG_CONFIG_HOMEdéfinit le répertoire de base par rapport auquel les fichiers de configuration spécifiques à l'utilisateur doivent être stockés. Si $XDG_CONFIG_HOMEn'est pas défini ou vide, une valeur par défaut égale à $HOME/.config doit être utilisée.

---

Citation:

---

Envoyé par Hominidé

d'après le document https://specifications.freedesktop.o...ec-latest.html...

---

Oui mais ce document concerne juste le toolkit "xdg" non ? :koi:
Or la configuration spécifique d'un toolkit en particulier ne fait pas jurisprudence pour les autres applications...:mrgreen:

Citation:

---

Envoyé par Sve@r

Oui mais ce document concerne juste le toolkit "xdg" non ? :koi:

---

Ce n'est pas ce que je comprends :
https://help.gnome.org/misc/release-...ns-xdg.html.fr
Les autres liens que j'ai lu vont dans ce sens ...

Et puisque nous sommes sur le forum python ---> https://www.it-swarm-fr.com/fr/pytho...hon/961208663/

XDG (= X Development Group) renommé en freedesktop utilisé par Gnome pour essayer de gérer le bazar des fichiers de configurations des applications sous Linux en s'inspirant de la registry Windows.

Et comme je le disais précédemment, si une application a des données spécifiques par utilisateur, l'endroit "normal" où les poser et le type de ces fichiers dépend de "standards" spécifiques à l'environnement système.

Après, on peut toujours choisir de ne pas les suivre pour ne pas s'em... à faire différent sur chaque environnement. Et avant de faire un choix, il faut connaître, s’intéresser aux différentes options.

- W

Citation:

---

Envoyé par Hominidé

Et puisque nous sommes sur le forum python ---> https://www.it-swarm-fr.com/fr/pytho...hon/961208663/

---

Ah c'est pas mal ça !!! Faudra que je teste (et surtout que je regade sous zindow ce que ça donne).

Maintenant wiztricks a bien résumé avec son "Après, on peut toujours choisir de ne pas les suivre pour ne pas...". Mais mes projets sont modulables. Si demain je veut faire plus finement ou travailler dans un autre dossier je modifie un seul point dans un seul source et tout le code s'y adapte 8-)

Citation:

---

Envoyé par Sve@r

Mais mes projets sont modulables.

---

C'est ce que disent tous les développeurs :mouarf: jusqu'au jour où il faut montrer que c'est modulable et qu'on doit commencer par concevoir une interface qui permette cette modularité.

En général changer un standard par d'un besoin client, et d'un commercial qui s'appuie sur ce que lui ont raconté les développeurs. Après les premiers chiffrages, on arbitre sur la perte de marge pour savoir si on se l'embourbe ou si on va rencontrer le client pour lui expliquer qu'on a été trop optimiste.... et que s'il passe commande on livrera AS_IS modulo une ristourne et la promesse de fonctionnalités dans un next major release.

- W

Citation:

---

Envoyé par wiztricks

C'est ce que disent tous les développeurs :mouarf: jusqu'au jour où il faut montrer que c'est modulable et qu'on doit commencer par concevoir une interface qui permette cette modularité.

---

Ah oui mais chez-moi c'est vraiment modulable :mrgreen:
J'ai un objet qui hérite de configparser.ConfigParser. Il prend en paramètre le nom du fichier de configuration et ensuite il gère tout lui-même.
Et mon appli commence par instancier sa configuration avec le nom (et chemin) du fichier de config, nom (et chemin) créé en fonction de l'os. Un nom de fichier utilisé une et une seule fois, c'est un peu la base de la modulabilarité 8-) non ?

Evidemment c'est modulable par le dev (moi) mais pas modifiable par le client :aie:

Techniquement, un objet qui hérite de ConfigParser est un ConfigParser avec l'API de ConfigParser. Si on doit remplacer çà par un fichier XML, il va y avoir un peu de boulot pour coller à cette API là.

Là c'est assez basique, çà ne va pas être difficile... si la bibliothèque était plus touffue pas évident d'espérer une correspondance 1<->1 côté API.

- W