2009-06-19 10 views
3

Lorsque votre application prend quelques paramètres de configuration (~ 5) et que l'application va pour être utilisée par des utilisateurs non technologiques (par exemple, KISS), comment gérez-vous généralement la lecture des options de configuration , puis passez les paramètres entre objets/fonctions (plusieurs modules)?Python - options de configuration, comment saisir/gérer?

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

J'utilise généralement optparse (Python) et passe les options/paramètres comme arguments ; mais je me demande s'il est plus commun d'utiliser un fichier texte de configuration qui est lu directement par tous les objets des modules (mais alors, n'est-ce pas comme ayant des variables 'globales' ?, et sans que personne ne «possède» l'état ?).

Un autre problème typique est le test unitaire; si je veux tester individuellement chaque module indépendamment, un module particulier peut nécessiter seulement 1 parmi les 5 options de configuration; comment déconnectez-vous habituellement les modules/objets individuels du reste de l'application, tout en autorisant à accepter 1 ou 2 paramètres requis (est-ce que le framework de test unitaire appelle ou prend en charge la fonctionnalité de configuration)? Je pense qu'il n'y a pas une façon unique et correcte de faire cela, mais il serait intéressant de lire sur les différentes approches, ou les modèles bien connus.

+0

Je ne suis pas sûr que la technique de "mise à jour" fonctionnera. SO ne fait rien de gracieux avec des mises à jour simultanées. La mise à jour de quelqu'un sera perdue. –

+0

n'avait pas utilisé suffisamment SO pour se rendre compte qu'il existe des problèmes de verrouillage et/ou de condition de course - merci pour votre réponse s.l. –

Répondre

0
"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. 
- 
- 
2

-vous l'habitude de lire les options de configuration via: - les options de ligne de commande/ interface utilisateur graphique - un fichier texte de configuration

deux. Nous utilisons settings.py de Django et logging.ini. Nous utilisons également des options de ligne de commande et des arguments pour les options qui changent le plus fréquemment.

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

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

[Partage options optparse est une grande douleur dans le cou et il va se fixe beaucoup de choses dans un désordre invérifiable.]

Quand vous faites du test par unité d'un seul module (PAS le « principal » module): (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 quand il y a des options?"]

La réponse est - nous n'avons pas. Puisque seule la méthode principale analyse les options de la ligne de commande, aucun autre module, fonction ou classe n'a d'idée sur les options de la ligne de commande. Il n'y a pas ce 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.