À quel moment un fichier de configuration devient-il un langage de programmation?

Cela fait un moment que je réfléchis aux fichiers de configuration et à leur relation avec le code et en fonction du jour et de la direction du vent, mes opinions semblent changer. Je reviens de plus en plus à la prise de conscience que j'ai eue pour la première fois en apprenant Lisp: il y a peu de différence entre les données et le code. Cela semble doublement vrai pour les fichiers de configuration. Considéré sous le bon angle, un script Perl n'est guère plus qu'un fichier de configuration pour Perl. Cela a tendance à avoir des conséquences assez lourdes pour des tâches telles que l'AQ et la division du travail, comme qui devrait être responsable de la modification des fichiers de configuration.

Le glissement du fichier de configuration au langage à part entière est généralement lent et semble être motivé par le désir d'avoir un système générique. La plupart des projets semblent commencer modestement avec quelques éléments de configuration comme où écrire les journaux, où rechercher les données, les noms d'utilisateur et les mots de passe, etc. Mais ensuite, ils commencent à se développer: les fonctionnalités commencent à pouvoir être activées ou désactivées, les temps et l'ordre des opérations commencent à être contrôlés, et, inévitablement, quelqu'un veut commencer à y ajouter de la logique (par exemple, utilisez 10 si la machine est X et 15 si la machine est Y). À un certain moment, le fichier de configuration devient un langage spécifique au domaine, et un langage mal écrit en plus.

Maintenant que je me suis lancé pour préparer le terrain, voici mes questions:

1. Quel est le véritable objectif d'un fichier de configuration?
2. Faut-il essayer de garder les fichiers de configuration simples?
3. Qui devrait être responsable de leur apporter des modifications (développeurs, utilisateurs, administrateurs, etc.)?
4. Devraient-ils être contrôlés à la source (voir question 3)?

Comme je l'ai dit plus tôt, mes réponses à ces questions changent constamment, mais pour le moment, je pense:

1. pour permettre à un non-programmeur de changer rapidement de gros morceaux de comportement
2. oui, tout ce qui n'est pas à grain grossier devrait être dans le code
3. les utilisateurs devraient être responsables des fichiers de configuration et les programmeurs devraient être responsables d'une couche de configuration entre les fichiers de configuration et le code qui donne un contrôle plus fin de l'application
4. non, mais la couche intermédiaire à grain plus fin doit être

Questions très intéressantes!

J'ai tendance à limiter mes fichiers de configuration à un format très simple «clé = valeur», car je suis entièrement d'accord avec vous que les fichiers de configuration peuvent très rapidement devenir des programmes à part entière. Par exemple, quiconque a déjà essayé de "configurer" OpenSER connaît le sentiment dont vous parlez: ce n'est pas de la configuration, c'est une programmation (douloureuse).

Lorsque vous avez besoin que votre application soit très "configurable" d'une manière que vous ne pouvez pas imaginer aujourd'hui, alors vous avez vraiment besoin d'un système de plugins . Vous devez développer votre application de manière à ce que quelqu'un d'autre puisse coder un nouveau plugin et le connecter à votre application à l'avenir.

Alors, pour répondre à vos questions:

1. Quel est le véritable objectif d'un fichier de configuration?

   Je dirais que pour permettre aux personnes qui installeront votre application de pouvoir tweek certains paramètres liés au déploiement, tels que le nom d'hôte, le nombre de threads, les noms des plugins dont vous avez besoin et les paramètres de déploiement de ces plugins (vérifiez sur la configuration de FreeRadius pour un exemple de ce principe), etc. Certainement pas l'endroit pour exprimer la logique métier.

2. Faut-il essayer de garder les fichiers de configuration simples?

   Absolument. Comme vous l'avez suggéré, "programmer" dans un fichier de configuration est horrible. Je pense que cela devrait être évité.

3. Qui devrait être responsable de leur apporter des modifications (développeurs, utilisateurs, administrateurs, etc.)?

   En général, je dirais les administrateurs, qui déploient l'application.

4. Devraient-ils être contrôlés à la source (voir question 3)?

   Je ne sont généralement pas source de contrôle des fichiers de configuration eux - mêmes, mais je fais source de contrôle d' un fichier de configuration du modèle, avec tous les paramètres et leurs valeurs par défaut, et des commentaires décrivant ce qu'ils font. Par exemple, si un fichier de configuration est nommé database.conf, je contrôle généralement à la source un fichier nommé database.conf.template. Maintenant, bien sûr, je parle de ce que je fais en tant que développeur . En tant qu'administrateur , je peux vouloir contrôler la source des paramètres réels que j'ai choisis pour chaque installation. Par exemple, nous gérons quelques centaines de serveurs à distance, et nous devons garder une trace de leurs configurations: nous avons choisi de le faire avec le contrôle de source.

Éditer: Bien que je pense que ce qui précède est vrai pour la plupart des applications, il y a toujours des exceptions, bien sûr. Votre application peut permettre à ses utilisateurs de configurer dynamiquement des règles complexes, par exemple. La plupart des clients de messagerie permettent aux utilisateurs de définir des règles pour la gestion de leurs e-mails (par exemple, «tous les e-mails provenant de 'john doe' et ne m'ayant pas dans le champ À: doivent être supprimés»). Un autre exemple est une application qui permet à l'utilisateur de définir une nouvelle offre commerciale complexe. Vous pouvez également penser à des applications comme Cognos qui permettent à leurs utilisateurs de créer des rapports de base de données complexes. Le client de messagerie offrira probablement à l'utilisateur une interface simple pour définir les règles, ce qui générera un fichier de configuration complexe (voire peut-être un peu de code). D'autre part, la configuration définie par l'utilisateur pour les offres commerciales peut être sauvegardée dans une base de données, de manière structurée (ni une simple structure clé = valeur, ni une portion de code). Et certaines autres applications peuvent même permettre à l'utilisateur de coder en python ou VB, ou dans un autre langage capable d'automatisation. En d'autres termes ... votre kilométrage peut varier.

D'accord. Vous aurez des utilisateurs qui veulent une configuration vraiment simple, vous devriez leur donner. En même temps, vous aurez des requêtes constantes de "Pouvez-vous ajouter ceci? Comment faire dans le fichier de configuration?", Je ne vois pas pourquoi vous ne pouvez pas supporter les deux groupes.

Le projet sur lequel je travaille actuellement utilise Lua pour son fichier de configuration. Lua est un langage de script, et il fonctionne assez bien dans ce scénario. Un exemple de notre configuration par défaut est disponible .

Vous noterez qu'il s'agit principalement d'instructions key = value, où value peut être l'un des types intégrés de Lua. Le plus compliqué qui soit, ce sont les listes, et elles ne sont pas vraiment compliquées (c'est juste une question de syntaxe).

Maintenant, j'attends simplement que quelqu'un demande comment définir le port de son serveur sur une valeur aléatoire à chaque fois qu'il le démarre ...

Récemment, je travaillais sur un projet et je me suis rendu compte que je voulais avoir des conditions dans mon fichier de configuration - qui auparavant était juste assez simple de la forme:

key = val
key2 = val
name = `hostname`

Je ne voulais pas écrire un mini-langage, car à moins de le faire très soigneusement, je ne pourrais pas permettre la flexibilité qui serait utile.

Au lieu de cela, j'ai décidé que j'aurais deux formes:

1. Si le fichier a commencé par "#!" et était exécutable, j'analyserais le résultat de son exécution.

2. Sinon je le lirais tel quel

Cela signifie que je peux maintenant autoriser les gens à écrire des "fichiers de configuration" qui ressemblent à ceci:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

De cette façon, j'obtiens la puissance d'un fichier de configuration dynamique si l'utilisateur veut l'utiliser, et la simplicité de ne pas avoir à écrire mon propre mini-langage.

Chaque schéma de fichier de configuration (suffisamment long) devient finalement un langage de programmation. En raison de toutes les implications que vous décrivez, il est sage pour le concepteur du fichier de configuration de se rendre compte qu'elle est en train de créer un langage de programmation et de planifier en conséquence, de peur qu'elle n'impose aux futurs utilisateurs un mauvais héritage.

J'ai une philosophie différente sur les fichiers de configuration. Les données sur la manière dont une application doit être exécutée sont toujours des données , et appartiennent donc à un magasin de données, et non au code (un fichier de configuration IMO est du code). Si les utilisateurs finaux doivent pouvoir modifier les données, l'application doit fournir une interface pour le faire.

J'utilise uniquement des fichiers de configuration pour pointer vers les magasins de données.

Vous pouvez vous tourner vers la théorie du calcul pour définir ce qui compte comme langage de programmation. Si le format de votre fichier de configuration est Turing Complete, il compte raisonnablement comme un langage de programmation. Selon cette définition, un format de fichier pour décrire les niveaux de Sokoban compte comme un langage de programmation (voir ici ). Il existe d'autres niveaux de complexité en dessous de Turing Complete qui peuvent également compter, comme les grammaires régulières et les automates pushdown .

Une autre façon de voir les choses est que de nombreux fichiers de configuration ne sont capables que de balisage de données, alors qu'un langage de programmation approprié doit être capable d'implémenter des algorithmes . Par exemple, JSON est un format de fichier de configuration, tandis que ECMA Script est un langage de programmation.

Voici mes pensées:

1. Pour permettre de modifier facilement le comportement d'exécution d'une application. Cela peut être le fait de programmeurs ou de non-programmeurs, selon les besoins. Cela peut être pendant le développement, mais je considère souvent les fichiers de configuration comme un moyen de rendre un programme plus flexible à tout moment.

2. Oui. Je pense que les fichiers de configuration doivent être aussi simples que possible, étant donné la contrainte que vous pouvez avoir besoin de diverses options pour contrôler différents comportements de votre environnement d'exécution. Je préfère regrouper les paramètres de configuration et les simplifier autant que possible.

3. Cela dépend de quoi et pourquoi le changement est effectué. Si les utilisateurs doivent le modifier, un frontal doit être créé pour les masquer des détails. La même chose est souvent vraie pour les non-développeurs en général.

4. Je contrôle souvent à la source la configuration "par défaut", mais j'ai un moyen de la remplacer par système pour le temps d'exécution réel.

Quant à l'ajout de logique au fichier de configuration, j'éviterais cela. Je pense qu'il vaut mieux que le fichier de configuration active la logique de votre application. Le comportement dans les fichiers de configuration conduit à un manque de maintenabilité et de compréhension, d'après mon expérience. Je préfère fortement garder les fichiers de configuration aussi simples que possible.

J'ai tendance à être d'accord avec la prémisse de cette question. J'évite de me créer des ennuis en prédisant tôt que cela va arriver, et donc je ne lance jamais mon propre système de configuration.

• Soit j'utilise la fonctionnalité de configuration des systèmes d'exploitation (comme plist, ou gconf ou tout ce qui est approprié),
• Ou un simple fichier plat, qui peut être géré par quelque chose comme un analyseur INI standard.
• Mordez la balle et branchez un analyseur de langage léger, généralement lua, parfois tcl dans l'application,
• Ou stocker des données dans une base de données relationnelle SQLite ou similaire.

Et me résigner à vivre avec la décision que j'ai prise, ou si je ne peux pas, refactoriser pour utiliser l'un des choix ci-dessus qui convient le mieux à l'application.

Le fait est qu'il n'y a vraiment aucune raison d'utiliser une solution de configuration locale. D'une part, il est plus difficile pour vos utilisateurs d'avoir à apprendre un nouveau format de configuration spécifique à une application. D'autre part, vous bénéficiez de tous les nombreux correctifs de bogues et mises à jour gratuits lorsque vous utilisez une solution standard. Enfin, le fluage des fonctionnalités est mis au repos, car, en fait, vous ne pouvez pas simplement ajouter une fonctionnalité de plus sans vraiment faire une révision majeure car le système de configuration n'est pas vraiment entre vos mains en premier lieu.

Cela dépend de ce que vous êtes d'accord avec les autres développeurs de l'équipe. Utilisez-vous des fichiers de configuration comme des fichiers de configuration ou créez une application pilotée par modèle .

Symptômes du fichier de configuration devenant un langage de programmation:

• nom = valeur les paires commencent à dépendre l'une de l'autre
• vous ressentez le besoin d'avoir un contrôle de flux (ex. si (ceci) que cela )
• la documentation du fichier de configuration devient essentielle afin de poursuivre le développement (au lieu de simplement utiliser l'application)
• avant que la valeur de la configuration ne soit lue, il faut avoir un certain contexte (c'est-à-dire que les valeurs dépendent de quelque chose d'extérieur au fichier de configuration lui-même)

Les fichiers de configuration progressent invariablement pour devenir des "langages de programmation à part entière" laids et illogiques. Il faut de l'art et des compétences pour concevoir de bons langages de programmation, et les langages de configuration devenus langage de programmation ont tendance à être épouvantables.

Une bonne approche consiste à utiliser un langage bien conçu, par exemple python ou ruby, et à l'utiliser pour créer un DSL pour votre configuration. De cette façon, votre langage de configuration peut rester simple en surface mais en fait être le langage de programmation à part entière.

Je pense que votre question est très pertinente étant donné le passage aux «interfaces fluides». De nombreux développeurs ont "vu la lumière" en ce qui concerne les applications configurées XML. L'utilisation de XML peut être très verbeuse et difficile à modifier correctement (surtout si aucun schéma n'est fourni). Avoir une interface fluide permet au développeur de configurer l'application dans un langage spécifique au domaine à l'aide de certaines paires clé-valeur à partir d'un fichier de configuration en texte brut (ou peut-être des paramètres de ligne de commande). Cela facilite également la configuration et la configuration de nouvelles instances de l'application à des fins de test ou autre.

Voici mes réponses à votre question:

• Quel est le véritable objectif d'un fichier de configuration?

Un fichier de configuration est un moyen de permettre à l'utilisateur de personnaliser le comportement de son programme au moment de l'exécution.

• Faut-il essayer de garder les fichiers de configuration simples?

Idéalement, je penserais que les fichiers de configuration devraient au moins être complétés par une interface fluide pour configurer le programme (cela est utile à bien des égards). Si vous avez besoin d'un fichier de configuration, il doit être très simple, rien d'autre que des paires clé-valeur.

• Qui devrait être responsable de leur apporter des modifications (développeurs, utilisateurs, administrateurs, etc.)?

Je pense que la réponse à cela dépend de votre organisation. Il devrait être de la responsabilité de la personne qui déploie le logiciel de s'assurer qu'il est correctement configuré.

• Devraient-ils être contrôlés à la source (voir question 3)?

Je vais voler cette réponse à quelqu'un d'autre :) J'aime l'idée de stocker une configuration de modèle dans le contrôle de source et de la modifier pour les besoins de chaque utilisateur local. Il y a de fortes chances que le fichier de configuration d'un développeur soit le cauchemar d'un autre développeur, il est donc préférable de laisser les choses qui varient selon l'utilisateur hors du contrôle de la source. Avoir un modèle est également un bon moyen de permettre à la personne qui déploie l'application (ou à d'autres développeurs) de voir exactement quelles valeurs sont valides pour le fichier de configuration.

J'ai vu des programmes python où le fichier de configuration est du code. Si vous n'avez pas besoin de faire quoi que ce soit de spécial (conditionnel, etc.), cela n'a pas l'air très différent des autres styles de configuration. par exemple, je pourrais créer un fichier config.pyavec des trucs comme:

num_threads = 13
hostname = 'myhost'

et le seul fardeau qui pèse sur l'utilisateur, par rapport aux (disons) fichiers INI, est qu'il doit mettre '' autour des chaînes. Vous pourriez sans doute faire la même chose dans d'autres langues interprétées. Il vous donne une capacité illimitée de compliquer votre fichier de configuration si nécessaire, au risque d'effrayer vos utilisateurs.

Oui, les fichiers de configuration doivent être simples. Ils ne doivent pas contenir eux-mêmes de «logique» - considérez-les comme une liste d'expressions dans des instructions if, et non comme des instructions conditionnelles dans leur intégralité.

Ils sont là pour permettre à l'utilisateur de décider quelles options codées dans l'application doivent être utilisées, alors n'essayez pas de les compliquer, cela finira par être autodestructeur - vous pourriez finir par écrire de simples fichiers de configuration pour contrôler comment le fichier de configuration d'origine doit être configuré autrement!

L'un des objectifs du travail «Oslo» chez Microsoft est de permettre (mais pas d'exiger) la résolution de ce problème.

1. Une application serait livrée avec des modèles de tous les nouveaux composants qu'elle comprend. Il utiliserait également les modèles existants. Par exemple, il peut inclure un service Web afin de pouvoir réutiliser le modèle système d'un service Web.
2. Les modèles comprendront des métadonnées les décrivant, y compris suffisamment d'informations pour que les outils puissent y accéder, sous forme textuelle ou graphique.
3. Certaines parties des modèles correspondront à la "configuration"

Cela signifie que l'équivalent des fichiers de configuration actuels peut être suffisamment riche pour prendre en charge l'édition textuelle et graphique de leur configuration. L'outil graphique sera fourni avec "Oslo" (nom de code "Quadrant").

Je serai le contrariant et je soumettrai que ce n'est qu'un langage quand il incarne plus que ce que peut représenter XML; ou bien quand XML est considéré comme un langage.

Alternativement, la plupart des fichiers de configuration peuvent être considérés comme des classes, mais avec uniquement des propriétés et aucune méthode. Et sans méthodes, je ne pense pas que ce soit une langue.

En fin de compte, le «langage» est une abstraction molle, mais oui, les bords sont ambigus.

Le code de nos applications devient moins important ... Il y a des scripts, il y a toutes sortes d'attributs qui définissent le comportement des classes, des méthodes, des arguments de méthode et des propriétés. Les utilisateurs peuvent définir des déclencheurs de base de données et des contraintes de base de données. Il peut y avoir des fichiers de configuration très compliqués. Parfois, l'utilisateur peut définir des feuilles de style XSLT pour manipuler l'entrée et la sortie car nos systèmes doivent être ouverts (SOA). Et il y a des choses comme BizzTalk qui nécessitent également une configuration complexe. Les utilisateurs peuvent définir des flux de travail complexes.

Nous devons écrire un meilleur code pour gérer cet environnement complexe, donc le code de nos applications devient plus important ...

Je suis un grand fan de l'utilisation de programmes python comme fichiers de configuration, en particulier pour les démons. J'aime prendre le virage de rendre le démon complètement vide de configuration à l'exception du "port de configuration". Le programme python se connecte ensuite au démon et procède à la création des objets dans le démon et les connecte ensemble pour créer la configuration souhaitée. Une fois que tout est configuré, le démon peut alors être laissé fonctionner seul. Les avantages, bien sûr, sont que vous obtenez un langage de programmation à part entière pour écrire vos fichiers de configuration et comme vous avez déjà un moyen de parler au démon à partir d'un autre programme, vous pouvez l'utiliser pour le débogage et obtenir des statistiques. Le principal inconvénient est de devoir gérer à tout moment les messages d'un autre programme.

Fichier de configuration : "Quel est mon but?"
Vous : "Configurez le beurre."
Fichier de configuration : "Ok ..."
Fichier de configuration : "Quel est mon but?"
Vous : "Vous configurez le beurre."
Fichier de configuration : "Oh mon Dieu."

1. Il n'y a pas de "véritable objectif" d'un fichier de configuration. C'est tout ce qui a du sens pour votre application. En général, les choses qui diffèrent (ou peuvent différer) entre les machines et qui ne changent pas au milieu de l'exécution de votre application devraient probablement se trouver dans un fichier de configuration. Les valeurs par défaut, les ports et les adresses pour d'autres services sont tous d'excellents candidats. Les clés et les secrets sont également d'excellents candidats, mais doivent être traités séparément de votre configuration normale pour des raisons de sécurité. Je ne suis pas d'accord avec le fait que le but d'un fichier de configuration est de permettre des modifications rapides. Le but devrait être de permettre une certaine flexibilité dans la configuration de votre application. Si un fichier de configuration est un moyen rapide et facile de permettre cette flexibilité, tant mieux - mais vous ne devriez pas avoir l'intention de modifier fréquemment vos fichiers de configuration.

2. Oui et non. Devez-vous essayer de simplifier le code de votre application? Oui. Vous devriez essayer de rendre tout ce que vous écrivez simple et précis. Pas plus compliqué que nécessaire. Il en va de même pour votre configuration. Cependant, c'est très spécifique à l'application. Le codage en dur de ce qui devrait être dans la configuration car cela rendrait votre configuration "trop ​​compliquée" est une mauvaise conception. En fait, essayer de "garder les choses simples" est la raison pour laquelle les fichiers de configuration finissent par être un désordre géant. Parfois, la démarche la plus simple consiste à modulariser. C'est pourquoi vos fichiers de configuration doivent être écrits dans un langage de programmation à usage général bien connu - pas un langage de configuration terrible (lire: tous les "langages de configuration" sont nulles ).

3. Encore une fois, qui devrait modifier les fichiers de configuration dépend complètement de l'application. Mais je suis d'accord avec miniquark, celui qui déploie l'application devrait être en charge de la configuration.

4. Contrôlez tout ce que vous pouvez à la source. Le contrôle de la source est excellent. Vous pouvez restaurer des éléments très facilement et vous avez un historique complet des modifications que vous avez apportées et un enregistrement de qui a effectué ces modifications. Alors pourquoi pas?