all fichiers de conf' - Page 1

Dans mon cas, c'est pour du Python, mais en fait la question est plus générale.

Comment déterminer où placer les fichiers de configuration ? Et là, c'est plus proche du Python, quel format utiliser ?

On peut distinguer deux cas :
- préférences utilisateur
OS X : ~/Library/Preferences/mon.programme.plist
Linux : ~/.config/mon.programme.xxx
Windows : ~/AppData/?

- préférences globales
OS X : /Library/Preferences/mon.programme.plist
Linux : ... bonne question ça sera dans /etc/mon.programme/preferences.xxx s'il est installé dans /usr/bin ou dans /bin,
mais s'il est installé dans /opt/bin, j'imagine que c'est mieux de mettre dans /opt/etc...
Et je ne sais pas comment déterminer l'emplacement facilement.
Windows : aucune idée

Sauriez-vous m'aider à remplir les trous ?

Je ne sais pas si on doit faire une distinction entre préférences globales d'un logiciel utilisateur et fichier de configuration pour un démon.

Pour un "démon" sous windows, il y a des clés de registres qui sont dédiées à ça.

Pour un démon :
/etc/enfer

Sérieusement, sous nux, pour la conf globale, tu peux faire
un ficher dans /etc/montruc/truc.emplacement.conf, éditable à souhait à la main

[/usr/bin]
conf=/etc/montruc/montruc.conf

[/opt/truc]
conf=/opt/truc/montruc.conf


Si t'as du mal, tu n'hésites surtout pas à utiliser ma librairie (conflib) qui rend tout ça super facile

Oui, mais comment le programme fait-il pour déterminer automatiquement l'emplacement du fichier ?


Par exemple, il y a OpenPKG qui est un système de packages qui s'installe sans les droits root dans une arborescence à part (/openpkg, je crois). Mettons qu'un paquet soit installé via OpenPKG. A priori, sa conf' sera dans /openpkg/etc uniquement (et on ne doit alors jamais toucher à /etc).

Et finalement, je crois que je vais finir par faire à nouveau ma lib de fichiers de conf' pour Python

T'as bien raison

(sinon, pour la première question, c'est SYMSTR GetCurFold () de mémoire )

L'emplacement du fichier doit être configurable par le mainteneur du package en principe.
Ça permet à chaque distribution de faire un package qui range les fichiers au bon endroit, vu que ça peut varier d'une distribution à l'autre en principe.

Par exemple, pour Debian les Debian Policies disent que :
Any configuration files created or used by your package must reside in /etc. If there are several, consider creating a subdirectory of /etc named after your package.

Pour les programmes en script je sais pas, mais pour les programmes compilés, on a souvent des ./configure qui prennent une option genre --conf-dir=/etc
Comme ça le mainteneur du package de la distribution a juste à passer au ./configure le chemin propre à la distrib cible quand il crée son package.

Bonne remarque, tiens. Ça doit être jouable de le passer en argument lors de la génération du paquet binaire, avec un choix par défaut « intelligent ».

Pour Windows, il ne faut pas hardcoder les chemins (même partiellement), parce que les noms et la hiérarchie peut changer suivant la langue, la version de l'OS, la config, etc.

À la place, tu as une API pour obtenir les chemins : http://msdn.microsoft.com/en-us/library/bb762181%28VS.85%29.aspx
Et la façon de l'appeler en Python : http://stackoverflow.com/questions/3858851/python-get-windows-special-folders-for-currently-logged-in-user

Les CSIDL à utiliser dans ton cas, si je ne dis pas de bêtises :
CSIDL_APPDATA pour les fichiers de config liés à l'utilisateur
CSIDL_LOCAL_APPDATA pour les fichiers de config liés à l'utilisateur, mais uniquement relatifs à la machine locale (donc pas accessibles si l'utilisateur se logue sur une autre machine du réseau)
CSIDL_COMMON_APPDATA pour les fichiers de config communs à tous les utilisateurs

La liste complète des constantes est là : http://msdn.microsoft.com/en-us/library/bb762494(v=vs.85).aspx

Les préférences globales sous GNU/Linux sont toujours dans /etc, ça ne fait pas partie du préfixe (genre /opt/foo, /usr/local ou /usr). Par exemple, Fedora crée un dossier /usr/etc, mais il est totalement vide; il n'existe apparemment que pour la compatibilité avec des logiciels tiers qui l'utilisent.

flanker (./1) :
On peut distinguer deux cas :
- préférences utilisateur
Linux : ~/.config/mon.programme.xxx

- préférences globales
Linux : ... bonne question ça sera dans /etc/mon.programme/preferences.xxx s'il est installé dans /usr/bin ou dans /bin,
mais s'il est installé dans /opt/bin, j'imagine que c'est mieux de mettre dans /opt/etc...

Cf. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Zerosquare (./8) :
Pour Windows, il ne faut pas hardcoder les chemins (même partiellement), parce que les noms et la hiérarchie peut changer suivant la langue, la version de l'OS, la config, etc.

À la place, tu as une API pour obtenir les chemins : http://msdn.microsoft.com/en-us/library/bb762181%28VS.85%29.aspx
Et la façon de l'appeler en Python : http://stackoverflow.com/questions/3858851/python-get-windows-special-folders-for-currently-logged-in-user

Les CSIDL à utiliser dans ton cas, si je ne dis pas de bêtises :
CSIDL_APPDATA pour les fichiers de config liés à l'utilisateur
CSIDL_LOCAL_APPDATA pour les fichiers de config liés à l'utilisateur, mais uniquement relatifs à la machine locale (donc pas accessibles si l'utilisateur se logue sur une autre machine du réseau)
CSIDL_COMMON_APPDATA pour les fichiers de config communs à tous les utilisateurs

La liste complète des constantes est là : http://msdn.microsoft.com/en-us/library/bb762494(v=vs.85).aspx

Ok, merci Ça me va parfaitement.

PpHd (./10) :

flanker (./1) :
On peut distinguer deux cas :
- préférences utilisateur
Linux : ~/.config/mon.programme.xxx

- préférences globales
Linux : ... bonne question ça sera dans /etc/mon.programme/preferences.xxx s'il est installé dans /usr/bin ou dans /bin,
mais s'il est installé dans /opt/bin, j'imagine que c'est mieux de mettre dans /opt/etc...

Cf. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Rien n'est défini sur ma Debian

Kevin Kofler (./9) :
Les préférences globales sous GNU/Linux sont toujours dans /etc, ça ne fait pas partie du préfixe (genre /opt/foo, /usr/local ou /usr). Par exemple, Fedora crée un dossier /usr/etc, mais il est totalement vide; il n'existe apparemment que pour la compatibilité avec des logiciels tiers qui l'utilisent.

Ça me facilite la vie, il est vrai

Bon, au final, je pars sur du fichier de conf' global toujours stocké dans /etc sur Linux.

En revanche, je suis un peu déçu par la lib Python, le module pour lire les .ini (ConfigParser) est vraiment pas terrible en Python 2 :
* pas de support d'unicode
* le format n'est pas génial en soi (à la relecture, pas moyen de faire la différence entre une chaîne et un entier)

Du coup, je me demande si je ne vais pas utiliser des plist (ou du JSON) systématiquement.


Sinon, rien sur la base de registre ? Ne sert-elle pas à stocker les conf', également ?

(contribution inutile, mais si les développeurs pouvaient enfin arrêter d'utiliser cette daube pour coller leur config...)

D'où ma question, justement je n'y connais rien â la BDR

Pour les bases, voir ici : http://msdn.microsoft.com/en-us/library/windows/desktop/ms724202(v=vs.85).aspx

Et l'API Python qui va avec :
http://docs.python.org/2/library/_winreg.html

C'est organisé en clés et sous-clés (~= dossiers), qui contiennent chacune une ou plusieurs valeurs (~= fichiers) ; chacune d'entre elles a un nom unique et un type. Dans la clé qui correspond à ton appli, tu es libre de créer des sous-clés et des valeurs comme ça t'arrange. Les valeurs peuvent être des blocs binaires, des chaînes, des tableaux de chaînes, ou des entiers.

Mais je crois que MS déconseille plus ou moins d'utiliser la base de registres sur les OS récents, même si je n'ai pas vraiment suivi l'évolution.

Call : GoldenCrystal appelé(e) sur ce topic...

À ma connaisance, la base de registre n'est pas obsolète et est loin de l'être. (C'est juste interdit pour les applications "Modern UI", mais vu que la quasi intégralité de Windows repose sur ce composant du système…)

Si tu prends l'exemple d'une plateforme comme .NET, l'intégralité de la configuration (à peu de choses prêt) est effectuée dans des fichiers XML (.config), que ce soit au niveau machine / serveur web / application / utilisateur. (La possibilité d'utiliser la base de registres est toutefois disponibles pour les paramètres application / utilisateur, avec un moindre effort, ce n'est juste pas le moyen par défaut ^^)
Par contre, si tu regardes la plupart des applications de Microsoft, tu as une palanquée de réglages stockés en registre, et ce n'est sans doute pas près de changer. (Peut-être avec la migration vers WinRT… Mais je n'y crois pas trop)

Pour ce qui est du stockage des fichiers, je pense que Zerosquare a tout dit en ./8. Il existe plus ou moins le même principe pour la base de registres : HKLM/Software/ pour les paramètres machine, HKCU/Software/ pour les paramètres utilisateur. (Il n'y a pas de notion de roaming par contre)
C'est loin d'être compliqué à utiliser pour stocker et récupérer des valeurs, mais ce n'est pas portable. Cependant, selon l'utilisation que tu en fais, c'est au minimum strictement équivalent à ce que tu ferais dans un fichier .ini basique (en pratique, c'est plus à cause de la structure en arbre et du typage des valeurs), donc ça peut bien se coller à une utilisation dans une librairie de configuration type .ini multiplateforme.

Le seul vrai "point noir", qui explique peut-être (en partie) le post ./13, c'est que tu ne peux pas juste copier coller un fichier pour recopier la configuration d'un PC à un autre. Cependant, pour une configuration simple, il suffit d'exporter la clé registre principale de l'application dans un fichier .reg pour pouvoir l'importer sur un autre PC. (Au final ce n'est pas plus ou pas moins le bordel qu'avec des fichiers de configuration, mais ça a l'avantage de ne pas trop polluer le disque en utilisation normale)

Ok, merci pour ces infos ^^
Ça correspond à peu près à ce que j'en savais, du coup.

Au niveau des fichiers XML, y a-t-il un format conseillé (un peu comme les plist) ?


Sinon, j'ai l'impression qu'il y a un peu deux façons de procédés pour utiliser des configurations :
* soit on définit un objet MaConfiguration avec les valeurs qu'on arrive à récolter (dans les fichiers de conf', par exemple) et quand on utilise un paramètre, on fournit en même temps une valeur par défaut si jamais la valeur n'est pas définie.

class MaConfig:
  pass
config = MaConfig()
config.read('/etc/toto.conf')
[...]
conn = mysql.connect(host=config.get('sql_host', 'mysql.com'), port=config.get('sql_port', 3306))

* soit on définit un objet MaConfiguration avec toutes les valeurs possibles (quitte à mettre une valeur par défaut lors de l'initialisation de l'objet), et on ne fournit jamais de valeur par défaut à l'utilisation

class MaConfig
  sql_host = 'mysql.com'
  sql_port = 3306
config = MaConfig()
config.read('/etc/toto.conf')
[...]
conn = mysql.connect(host=config.sql_host, port=config.sql_port)

J'ai l'impression que toutes les libs que j'ai vues en Python se basent plutôt sur la première idée. Perso, je trouve la seconde solution plus propre, vu qu'au moins, on n'a pas besoin de parcourir tout le code à la recherche des paramètres planqués, et qu'on peut générer facilement un fichier de configuration par défaut avec toutes les valeurs.

La deuxième méthode est moins pratique quand tu veux faire une bibliothèque de lecture de fichiers de configuration réutilisable. Tu es obligé de générer une classe MaConfig automatiquement ou de forcer l'utilisateur de la bibliothèque à la créer manuellement.

KDE gère d'ailleurs les 2 méthodes, la première est l'API normale de KConfig, mais tu as KConfigXT qui permet de générer une classe implémentant la deuxième solution (en utilisant KConfig en interne) automatiquement à partir d'une définition simple (fichier .kcfg).

Le but est justement de forcer l'utiliser à hériter d'une classe, en rajoutant simplement les attributs dont il a besoin.
Au moins, quand tu regardes le code, tu es sûr d'avoir un seul endroit à regarder. Idem pour changer les paramètres par défaut.

Mouais… Ça marche en un langage qui utilise l'une ou l'autre forme d'introspection, pas vraiment en C++ (sauf à la limite avec QObject), la classe de base devant remplir les champs de la classe dérivée (inversion de la dépendance). Mais tu as raison, en Python ou un autre langage de script, effectivement, ça peut se faire.

On peut aussi utiliser un tableau associatif. Mais sinon, l'utilisation d'une configuration par défaut mise à jour à partir du fichier de configuration me semble bien meilleure, car elle ne nécessite pas de copies d'une valeur par défaut lorsqu'une option est utilisée à plusieurs endroits. Et ça évite aussi d'avoir à rechercher tous les endroits où cette option est utilisée lorsqu'on veut en changer la valeur par défaut et ainsi de se retrouver avec des valeurs incompatibles. Ça augmente aussi la généricité du code, car plusieurs utilisations peuvent nécessiter des valeurs par défaut différentes.

C'est bien pour ça qu'il y a KConfigXT.