À 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 au code et, selon le jour et la direction du vent, mes opinions semblent changer. De plus en plus, je reviens toujours à la réalisation que j’avais tout 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. Lorsque regardé dans la bonne lumière, un script Perl est un peu plus qu’un fichier de configuration pour perl. Cela a tendance à avoir des conséquences assez lourdes sur des tâches telles que l’assurance qualité et la division du travail, par exemple, qui devrait être responsable de la modification des fichiers de configuration.

Le fluage du fichier de configuration vers un langage complet est généralement lent et semble motivé par le désir de disposer d’un système générique. La plupart des projets semblent modestes avec quelques éléments de configuration tels que l’emplacement où écrire les journaux, où rechercher les données, les noms d’utilisateur et les mots de passe, etc. Mais ils commencent à se développer: les timings et l’ordre des opérations commencent à être contrôlés et, inévitablement, quelqu’un veut y append de la logique (par exemple, utilisez 10 si la machine est X et 15 si la machine est Y). À un moment donné, le fichier de configuration devient un langage spécifique au domaine et un langage mal écrit.

Maintenant que je suis passé à autre chose, voici mes questions:

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

Comme je l’ai dit plus tôt, mes réponses à ces questions changent constamment, mais je pense en ce moment:

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

    Des questions très intéressantes!

    J’ai tendance à limiter mes fichiers de configuration à un format très simple “clé = valeur”, car je suis tout à fait d’accord avec vous pour dire que les fichiers de configuration peuvent très rapidement devenir des programmes complets. Par exemple, quiconque a déjà essayé de “configurer” OpenSER connaît le sentiment dont vous parlez: ce n’est pas la configuration, c’est la 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 plug-in et le connecter à votre application à l’avenir.

    Donc, pour répondre à vos questions:

    1. Quel est le véritable objective d’un fichier de configuration?

      Je dirais, pour permettre aux personnes qui installeront votre application de pouvoir tweeter certains parameters 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 parameters de déploiement pour ces plugins sur la configuration de FreeRadius pour un exemple de ce principe), etc.

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

      Absolument. Comme vous l’avez suggéré, la “programmation” dans un fichier de configuration est horrible. Je crois que cela devrait être évité.

    3. Qui devrait être responsable de les modifier (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 la question 3)?

      Je ne contrôle généralement pas les fichiers de configuration eux-mêmes, mais je contrôle le fichier de configuration d’un modèle, avec tous les parameters et leurs valeurs par défaut, et des commentaires décrivant ce qu’ils font. Par exemple, si un fichier de configuration s’appelle database.conf , je contrôle généralement 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 souhaite peut-être contrôler les parameters que j’ai choisis pour chaque installation. Par exemple, nous gérons quelques centaines de serveurs à distance, et nous devons suivre leurs configurations: nous avons choisi de le faire avec le contrôle des sources.


    Edit : Bien que je pense que ce qui précède soit vrai pour la plupart des applications, il y a toujours des exceptions, bien sûr. Votre application peut permettre à ses utilisateurs de configurer dynamicment 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 emails (par exemple, “tous les emails provenant de” john doe “et ne pas m’avoir dans le champ” To “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 telles que Cognos qui permettent à leurs utilisateurs de créer des rapports de bases 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 (ou peut-être même un peu de code). D’autre part, la configuration définie par l’utilisateur pour les offres commerciales peut être enregistrée dans une firebase database, de manière structurée (ni une clé simple = structure de la valeur, ni une partie du code). Et certaines autres applications pourraient même permettre à l’utilisateur de coder en Python ou VB, ou un autre langage compatible avec l’automatisation. En d’autres termes, votre kilométrage peut varier.

    D’accord. Vous aurez des utilisateurs qui veulent une configuration très simple, vous devriez la leur donner. Dans le même temps, vous aurez des requêtes constantes de “Pouvez-vous append ceci? Comment puis-je 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 fonctionne très bien dans ce scénario. Il existe un exemple de notre configuration par défaut .

    Vous noterez que ce sont principalement les instructions key = value, où value peut être l’un des types intégrés de Lua. La chose la plus compliquée, 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 leur serveur sur une valeur aléatoire à chaque fois qu’ils le démarrent …

    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 était auparavant assez simple:

    key = val key2 = val name = `hostname`
    key = val key2 = val name = `hostname` 

    Je ne voulais pas écrire une mini-langue, car si je ne le faisais pas avec beaucoup de soin, je ne pouvais pas permettre la flexibilité qui serait utile.

    Au lieu de cela, j’ai décidé d’avoir deux formes:

    1. Si le fichier a commencé par “#!” et était exécutable j’parsingr le résultat de l’exécuter.

    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) 
     {
        imprimer << EOF;
     foo = moi
     bar = vous
     EOF
     }
     autre
     {
        imprimer << EOF;
     foo = bar
     bar = foo
     EOF
     }
    

    De cette façon, j'obtiens la puissance d'un fichier de configuration dynamic 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 éventuellement un langage de programmation. En raison de toutes les implications que vous décrivez, il est sage pour le concepteur de fichier de configuration de réaliser qu’elle est en train de créer un langage de programmation et de planifier en conséquence, de peur d’imposer un inheritance aux futurs utilisateurs.

    J’ai une philosophie différente sur les fichiers de configuration. Les données sur la façon dont une application doit être exécutée sont des données fixes et appartiennent donc à un magasin de données et non à un 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.

    Je n’utilise que des fichiers de configuration pour pointer sur des 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 votre format de fichier de configuration est Turing Complete, cela compte comme un langage de programmation. Par cette définition, un format de fichier pour décrire les niveaux de Sokoban est considéré comme un langage de programmation (voir ici ). Il existe d’autres niveaux de complexité en dessous de Turing Complete, tels que 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 du balisage de données, alors qu’un langage de programmation correct doit pouvoir 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. Permettre au comportement d’exécution d’une application d’être modifié facilement. Cela peut être fait par des programmeurs ou des non-programmeurs, en fonction des besoins. Cela peut être au cours du 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é 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 parameters de configuration et les simplifier autant que possible.

    3. Dépend de quoi et pourquoi le changement est effectué. Si les utilisateurs vont le changer, un front-end doit être fait pour les cacher 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 configuration “par défaut”, mais j’ai la possibilité de la remplacer par système pour le temps d’exécution réel.

    En ce qui concerne 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, selon 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 m’attirer des ennuis en prédisant tôt que cela va se produire, et par conséquent, ne lancez jamais mon propre système de configuration.

    • Soit j’utilise la configuration de la configuration du système d’exploitation (telle qu’un plist, ou gconf ou autre),
    • Ou un simple fichier plat, qui peut être manipulé par quelque chose comme un parsingur INI standard.
    • Mordre la balle et twigr un parsingur de langage léger, généralement lua, parfois tcl dans l’application,
    • Ou stocker des données dans une firebase database 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 mieux à l’application.

    Le fait est qu’il n’y a pas vraiment de raison d’utiliser une solution de configuration maison. D’une part, il est plus difficile pour vos utilisateurs d’apprendre un nouveau format de configuration spécifique à l’application. D’autre part, vous bénéficiez de toutes les nombreuses corrections de bogues et mises à jour qui sont gratuites lorsque vous utilisez une solution standard. Enfin, le ralentissement des fonctionnalités est mis au repos, car, en fait, vous ne pouvez pas simplement append une fonctionnalité supplémentaire sans vraiment procéder à une révision majeure, car le système de configuration n’est pas vraiment entre vos mains.

    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 fichiers de configuration ou créez-vous une application pilotée par un modèle .

    Les symptômes du fichier de configuration deviennent un langage de programmation:

    • les paires nom = valeur commencent à dépendre l’une de l’autre
    • vous ressentez le besoin d’avoir un contrôle de stream (ex. si (ceci) que cela )
    • la documentation du fichier de configuration devient essentielle pour poursuivre le développement (au lieu de simplement utiliser l’application)
    • avant que la valeur de config ne soit lue, il faut avoir un certain contexte

    Les fichiers de configuration sont invariablement en train de devenir des “langages de programmation à part entière” illogiques et illogiques. Il faut de l’art et des compétences pour concevoir de bons langages de programmation, et les langages de configuration transformés en langage de programmation ont tendance à être horribles.

    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 restr 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 en XML. Utiliser XML peut être très verbeux et difficile à éditer 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 à un domaine à l’aide de certaines paires clé-valeur à partir d’un fichier de configuration en texte brut (ou peut-être de parameters de ligne de commande). Il est également très facile de configurer et de configurer de nouvelles instances de l’application pour les tester ou autres.

    Voici mes réponses à votre question:

    • Quel est le véritable objective d’un fichier de configuration?

    Un fichier de configuration est un moyen permettant à 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 pense que les fichiers de configuration devraient au moins être complétés par une interface fluide pour configurer le programme (ceci est utile à de nombreux égards). Si vous avez besoin d’un fichier de configuration, il devrait être très simple, rien d’autre que des paires clé-valeur.

    • Qui devrait être responsable de les modifier (développeurs, utilisateurs, administrateurs, etc.)?

    Je pense que la réponse à cela dépend de votre organisation. Il est de la responsabilité de la personne déployant le logiciel de s’assurer qu’elle est correctement configurée.

    • Devraient-ils être contrôlés à la source (voir la 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 code source et de la modifier pour les besoins de chaque utilisateur local. Les chances sont 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 des choses qui varient d’un utilisateur à l’autre. Avoir un modèle est également un bon moyen de permettre à la personne déployant 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 quelque chose de spécial (conditionnel, etc.), il ne ressemble pas beaucoup aux autres styles de configuration. Par exemple, je pourrais créer un fichier config.py avec des éléments tels que:

     num_threads = 13 hostname = 'myhost' 

    et le seul fardeau pour l’utilisateur, comparé aux fichiers (disons) INI, est qu’ils doivent contourner les chaînes. Vous pouvez sans doute faire la même chose dans d’autres langages interprétés. Cela vous donne une capacité illimitée de compliquer votre fichier de configuration si nécessaire, au risque de faire peur à vos utilisateurs.

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

    Ils sont là pour permettre à l’utilisateur de choisir laquelle des options codées dans l’application doit être utilisée, alors n’essayez pas de les rendre compliquées, elles finiront par s’autodétruire – vous pourriez finir par écrire des fichiers de configuration simples contrôler comment le fichier de configuration d’origine doit être configuré autrement!

    L’un des objectives du travail “Oslo” chez Microsoft consiste à permettre (mais pas à exiger) la résolution de ce problème.

    1. Une application serait livrée avec des modèles de tout nouveau composant inclus. Il utiliserait également des modèles existants. Par exemple, il peut inclure un service Web, de sorte qu’il puisse réutiliser le modèle de système d’un service Web.
    2. Les modèles incluront des métadonnées les décrivant, y compris suffisamment d’informations pour que les outils puissent y accéder, que ce soit textuellement ou graphiquement.
    3. Des parties des modèles correspondront à “configuration”

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

    Je serai le contrarian et soumettrai que c’est seulement un langage quand il incarne plus que peut être représenté par XML; ou bien lorsque 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 un langage.

    En fin de compte, “langage” est une abstraction molle, mais oui, les contours sont ambigus.

    Le code de nos applications devient moins important … Il existe des scripts, il y a toutes sortes d’atsortingbuts 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 firebase database et des contraintes de firebase database. 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 les entrées et les sorties, 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 stream de travail complexes.

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

    Je suis un grand fan de l’utilisation des programmes python en tant que 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 continue à créer des objects dans le démon et à les connecter ensemble pour créer la configuration souhaitée. Une fois que tout est mis en place, le démon peut alors être exécuté seul. Les avantages, bien sûr, sont que vous obtenez un langage de programmation complet pour écrire vos fichiers de configuration et que vous avez déjà un moyen de parler au démon depuis un autre programme, vous pouvez l’utiliser pour déboguer et obtenir des statistiques. L’inconvénient majeur est d’avoir à gérer des messages provenant d’un autre programme à tout moment.

    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 “but réel” d’un fichier de configuration. C’est ce qui a du sens pour votre application. En général, les éléments qui diffèrent (ou peuvent différer) d’une machine à l’autre et ne changent pas au milieu de l’exécution de votre application doivent probablement se trouver dans un fichier de configuration. Les valeurs par défaut, les ports et les adresses pour les 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 pour dire que le but d’un fichier de configuration est de permettre des modifications rapides. L’objective devrait être de permettre une flexibilité dans la configuration de votre application. Si un fichier de configuration est un moyen simple et rapide 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. Devriez-vous tenter de rendre le code de votre application simple? Oui. Vous devriez essayer de rendre tout ce que vous écrivez simple et précis. Pas plus compliqué que nécessaire. La même chose est vraie de votre configuration. Cependant, ceci est très spécifique à l’application. Coder en dur 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 devenir un gâchis géant. Parfois, le plus simple est de modulariser. C’est pourquoi vos fichiers de configuration doivent être écrits dans un langage de programmation bien connu – et non dans un langage de configuration épouvantable (lisez: toutes les “langues de configuration” sont vaines ).

    3. Encore une fois, ceux qui devraient modifier les fichiers de configuration dépendent entièrement de l’application. Mais je suis d’accord avec miniquark, quiconque déploie l’application doit être en charge de la configuration.

    4. Source contrôle tout ce que vous pouvez. Le contrôle de la source est génial. Vous pouvez retourner des choses très facilement et vous avez un historique complet des modifications que vous avez apscopes et un enregistrement de qui a effectué ces modifications. Alors pourquoi pas?