Python - options de configuration, comment entrer / manipuler?

Question

Lorsque votre application prend quelques (~ 5) paramètres de configuration et que l'application est en cours à utiliser par les utilisateurs non technologiques ( KISS ), comment gérez-vous généralement la lecture options de configuration, puis transmission des paramètres entre objets / fonctions (plusieurs modules)?

Exemples d'options: répertoires / noms de fichiers d'entrée et de sortie, niveau de verbosité.

J'utilise généralement optparse (Python) et transmets les options / paramètres comme arguments; mais je me demande s'il est plus courant d'utiliser un texte de configuration fichier lu directement par les objets de tous les modules (mais alors, n’est-ce pas comme avoir des variables "globales"?, et sans personne "propriétaire" de l'état?).

Les tests unitaires sont un autre problème typique. si je veux tester chaque unité seul module indépendamment, un module particulier peut ne nécessiter que 1 des 5 options de configuration; comment découplez-vous habituellement un individu modules / objets du reste de l'application, tout en lui permettant de accepte 1 ou 2 paramètres requis (le framework de test unitaire est-il en quelque sorte invoquer ou prendre en charge la fonctionnalité de configuration)?

À mon avis, il n’existe pas de façon unique et correcte de le faire, mais ce serait être intéressant à lire sur les différentes approches, ou les modèles bien connus.

Answer 1

"Counts answer"
Please update these counts and feel free to add/modify.

Do you usually read config options via:
- command-line/gui options : 1
- a config text file       : 0


How do multiple modules/objects have access to these options?
- they receive them from the caller as an argument: 1
- read them directly from the config text file:     0


When doing unit-testing of a single module (NOT the "main" module)
and the module uses one option, e.g. input filename:
- unit-test framework provides own "simplified" config functionality: 0
- unit-test framework invokes main app's config functionality:        1


Do you use:
- optparse:  1
- getopt:    0
- others?


Please list any config management "design pattern" 
(usable in Python) and add a count if you use it - thanks.
- 
-

Answer 2

Lisez-vous habituellement les options de configuration via: - options de ligne de commande / gui - un fichier texte de configuration

Les deux. Nous utilisons les fichiers settings.py et logging.ini de Django. Nous utilisons également des options de ligne de commande et des arguments pour les options les plus fréquemment modifiées.

Comment plusieurs modules / objets ont-ils accès à ces options?

• settings.py; logging.ini - ne peut pas dire.
• Nos options sont privées du programme principal et utilisées pour construire
  arguments aux fonctions ou aux initialiseurs d'objet.

[Partager les options optparse est très pénible et oblige inutilement beaucoup de choses dans un gâchis incontrôlable.]

Lors des tests unitaires d'un seul module (PAS du module "principal"): (par exemple, option de lecture spécifiant le nom du fichier d'entrée)

[Je ne peux pas analyser la question. Je suppose que c’est "comment testez-vous s’il ya des options?"]

La réponse est: nous ne le faisons pas. Étant donné que seule la méthode principale analyse les options de ligne de commande, aucun autre module, fonction ou classe n’a une idée des options de ligne de commande. Il n’existe pas de module "nécessite 1 des 5 options de configuration". Les classes (ou fonctions) du module ont des arguments ordinaires et c'est tout.

Nous utilisons uniquement optparse .