Конфиг
Файл конфигурации или конфигурационный файл используется для хранения настроек компьютерных программ, в том числе и операционных систем.
Как правило, конфигурационные файлы имеют текстовый формат и могут быть прочитаны и отредактированы пользователем программы.
Наиболее широко файлы конфигурации в качестве средства настройки используются в ОС семейства Unix: GNU/Linux и др.
Известные форматы
В ОС GNU/Linux в качестве файлов конфигурации системы зачастую используются сценарии (скрипты) для командной оболочки.
Смотреть что такое «Конфиг» в других словарях:
Сравнение графических процессоров ATI — Эта таблица содержит основную информацию о графических процессорах ATI и видеокартах, построенных на официальных спецификациях ATI Technologies. Содержание 1 Замечания о версиях DirectX 2 Замечания о версиях OpenGL … Википедия
Сравнение графических процессоров AMD — Эта таблица содержит основную информацию о графических процессорах AMD и видеокартах, построенных на официальных спецификациях AMD. Содержание … Википедия
CS-Redemax — System URL: CS REDEMAX System Коммерческий: Нет Тип сайта: Игры Регистрация … Википедия
Кубски, Филип — Филип «Neo» Кубски Личная информация Полное имя: Филип Кубски Гражданство … Википедия
Samba-swat — Логотип Samba Тип Конфигуратор Разработчик The Samba Team Версия 3.2.4 (18 сентября … Википедия
Radeon R700 — кодовое название линейки GPU, производимых графическим подразделением AMD. Первым чипом из серии стал RV770. GPU был продемонстрирован как часть FireStream 9250 и Cinema 2.0 16 июня 2008 года[1]. Серия видеокарт на его основе Radeon HD4800 были… … Википедия
Что такое config?
Что такое коммит?
Что такое коммит в данном контексте:
10 000 коммитов в проект Open Source.
Что такое интерфейс?
Пожалуйста объясните, зачем в программировании нужны интерфейсы?
Что такое локализация?
Привет Всем! Скажите пожалуйста, как вы понимаете слово локализация? Есть текст Описание.
что такое АБСТРАКЦИЯ?
Шишку на голове набил, с этим вопросом. что такое абстракция.
Решение
Это особая вишенка женской логики, демонстрирующая всю суть многоуровневых иерархий данных, которых хранилище типа «конфиг» может вместить в себя 
Добавлено через 16 секунд
Что такое сервер?
Кто может объяснить, что такое сервер, только не в плане железа, а софта. То есть тот сервер на.
Что такое информация?
В прошлом веке термин информация стал чуть ли не ключевым словом, в веке нынешнем на эту информацию.
Что такое DevOps?
Доброго времени суток! Что это значит? Может пишу в не в том разделе. Читал в интернете не понял.
Что такое API
В википедии прочитал определение и некоторое представление появилось. Например, у меня есть.
От новичка в эксперты: пишем файл конфигурации для вашего Python приложения
Относитесь к файлу конфигурации, использующемуся в приложении, как к разрабатываемому вами коду.
Когда мы разрабатываем программное обеспечение, то всегда прикладываем много усилий для написания качественного и производительного кода. Однако зачастую этого недостаточно.
Разработка качественного программного обеспечения, включает заботу о разработке своей экосистемы, например, для организации процессов тестирования, развертывания, сетевого обмена данными и т.д. Одним из наиболее важных аспектов, который необходимо при этом учитывать, является реализация гибкого механизма управления конфигурацией (настройками) программного обеспечения.
Правильная реализация управления конфигурацией по сути должна позволять запускать программное обеспечение в любой среде без внесения изменений в его исходный код. Этот подход обеспечивает эффективное управление проблемными настройками вашего приложения со стороны администраторов Ops, обеспечивает представление информации о том, что может произойти во время его функционирования, а также позволяет изменять его поведение во время выполнения.
Наиболее распространенные конфигурации включают в себя учетные данные для базы данных или внешней службы, имя хоста сервера, а также любые динамические параметры и т.д.
В этой статье я хочу поделиться с вами несколькими зарекомендовавшими себя практиками управления конфигурациями, а также как мы можем реализовать их в приложениях, написанных на Python.
Когда необходим файл конфигурации приложения?
Перед разработкой конфигурационного файла сначала необходимо спросить себя, нужен ли вообще какой-либо внешний файл с данными? Разве мы не можем просто поместить их в виде константных значений прямо в исходном коде? Собственно, достаточно известная концепция The Twelve-Factor App давно отвечает на этот вопрос:
Лакмусовой бумажкой для проверки правильности решения о выделении config всей конфигурационной информации приложения из кода, является рассмотрение возможности о публикации в любой момент кодовой базы вашего приложения, то есть можно ли сделать его исходный код открытым, без нарушения конфиденциальности чьих-либо учетных данных.
Обратите внимание, что это определение config не включает внутреннюю конфигурацию приложения, такую как, например, как config/routes.rb в Rails, или способ подключения модулей в Spring. Перечисленные выше примеры способов конфигурации не меняются в зависимости от среды развертывания, и поэтому это лучше всего реализовать их в коде.
Подходы рекомендованные этой концепцией предписывают, чтобы любые параметры, зависящие от среды, такие как учетные данные базы данных, находились во внешнем файле. В противном случае их реализуют просто обычными константами в коде. Другой вариант использования, который я часто вижу, – это хранение динамических переменных (данных) во внешнем файле (базе данных), например, черный blacklist или белый whitelist список пользователей. Ими могут быть числа в заданном диапазоне (например, длительность тайм-аута) или любые текстовые файлы с произвольным содержимым. Отметим, что эти динамические переменные (данные) остаются неизменными вне зависимости от особенностей исполняемой среды.
В свою очередь файл конфигурации делает программное обеспечение более гибким и легким для редактирования его функциональных возможностей. Однако, если он слишком сильно разрастается, рациональнее все таки перенести его в базу данных.
Какой формат файла конфигурации использовать?
С практической точки зрения, на формат файла конфигурации нет никаких технических ограничений, если код приложения может его прочитать и анализировать. Но есть и более рациональные практики для выбора формата файла с настройками. Так наиболее распространенными, стандартизованными форматами являются YAML, JSON, TOML и INI. Самый подходящий формата для файл конфигурации должен соответствовать как минимум трем критериям:
Возможно вам пока не ясно какой из форматов файла лучше использовать. Но если вы подумаете об этом в контексте программирования на языке Python, то наиболее очевидным ответом будет YAML или INI. Форматы YAML и INI хорошо понятны большинству программ и пакетов Python.
INI файл, вероятно, является наиболее простым решением для сохранения настроек приложения, имеющих только один уровень иерархии (вложенности) параметров. Однако формат INI не поддерживает других типов данных, кроме строк: в нем все данные имеют строковое представление.
Та же конфигурация настроек в YAML выглядит следующим образом.
Как видите, YAML изначально поддерживает использование вложенные структуры (также как и JSON) с помощью отступов. Кроме того, YAML, в отличие от формата INI файлов, поддерживает некоторые другие типы данных такие как целые и с плавающей запятой числа, логические значения, списки, словари и т.д.
Формат файлов JSON по сути очень похож на YAML и тоже чрезвычайно популярен, однако в JSON файлы нельзя добавлять комментарии. JSON, как текстовый формат содержащий структурированные данные, часто используется для хранения внутренней конфигурации внутри программы, но совершенно не предназначен для того, чтобы делиться конфигурацией приложения с другими людьми (в особенности с далекими от вопросов разработки ПО).
Формат TOML, с другой стороны, похож на INI, но поддерживает гораздо больше типов данных, а также специальный синтаксис для хранения вложенных структур. Его часто используют менеджеры пакетов Python такие, например, pip или poetry. Но если в файле конфигурации присутствует слишком много вложенных структур, то YAML в этом отношении, с моей точки зрения, наилучший выбор. Следующий ниже фрагмент файла выглядит как INI, но в отличие от него каждое строковое значение имеет кавычки.
Пока что мы выяснили ЧТО из себя представляют форматы файлов YAML, JSON, TOML и INI, далее мы рассмотрим КАК они могут быть использованы.
YAML/JSON — простое чтение внешнего файла
Как обычно, мы начнем с самого простого, то есть создадим внешний файл с настройками, а затем прочитаем его. Python имеет в своем составе встроенные пакеты для чтения и анализа файлов YAML и JSON. И как видно из приведенного ниже кода, они фактически возвращают один и тот же объект типа dict, поэтому доступ к его атрибутам будет одинаковым для обоих файлов.
Чтение
Валидация
Пакет Cofigureparser из состава стандартной библиотеки Python
В этом разделе рассмотрим пакеты, предназначенные непосредственно для управления конфигурацией приложения. И начнем со встроенного в стандартную библиотеку Python пакета: Configureparser.
Configureparser в большинстве случаев используется для чтения и записи INI файлов, и поддерживает чтение входных данных из файла сразу в виде словаря или итерируемого iterable файлоподобного объекта. Как известно, каждый файл INI состоит из нескольких секций, содержащих настройки в виде пар ключ-значение. Ниже приведен простой пример кода для доступа к полям настроек.
Чтение
Валидация
Валидация данных с Configureparser не так проста, как для пакетов, работающих с форматами YAML и JSON. Во-первых, он не возбуждает исключения FileNotFoundError если файла настроек не существует, а вместо этого вызывает исключение типа KeyError, как при попытке доступа к отсутствующему ключу.
Тем не менее, Configureparser может возбуждать исключение ParserError при наличии нескольких ошибок (см. пример кода с тестами ниже). И в большинстве случаев этого достаточно для определения проблемных мест в самом файле настроек.
Python-dotenv — считываем конфигурацию приложения из переменных среды
Чтение
Валидация
Dynaconf — мощный конфигуратор настроек для приложений Python
Чтение
Валидация
Одна из наиболее интересных, в частности для меня, возможностей dynaconf – это его настраиваемый валидатор. Как упоминалось ранее, Configureparser недостаточно строго проверяет корректность INI файлов настроек, но это можно легко реализовать в dynaconf. В следующем примере мы проверяем, существуют ли определенные ключи в файле с настройками и имеется ли в нем конкретный ключ с корректным значением. Если вы читаете настройки из файла YAML или TOML, которые как мы говорили ранее, поддерживают несколько типов данных, то вы даже можете проверить, находится ли значение настройки, например, число в заданном диапазоне.
Интеграция с Pytest
Обновляем конфигурацию приложения во время его выполнения
Hydra — упрощаем разработку, динамически создавая иерархическую структуру конфигурации приложения
Рассмотрим последним, в этой статье, способ создания и поддержки конфигурации для вашего приложения, который по сути является гораздо большим, чем просто загрузчик и парсер файлов с настройками.
Hydra – это платформа, разработанная Facebook для гибкой и элегантной настройки самых сложных приложений. Которая помимо чтения, записи и валидации корректности файлов конфигурации, реализовывает свою достаточно рациональную стратегию упрощения управления несколькими конфигурационными файлами, переопределения (перезаписи) их с использованием интерфейса командной строки, создания snapshot снимка состояния приложения перед каждым его запуском (между перезапусками) и т.д.
Чтение
Валидация
Hydra прекрасно интегрируется с декоратором @dataclass для выполнения основных проверок корректности, таких как проверка типов или значения полей. Однако у нее нет поддержки __post_init__ метода расширенной проверки значений, как это описано в моей предыдущей статье.
Группа конфигураций
Когда конфигурация приложения станет более сложной, то в вашей программе она может иметь следующую структуру (пример из документации Hydra).
Далее…
В этом случае в основном потоке запускаются 6 задач одновременно:
Вывод
В этой статье мы рассмотрели несколько способов управления конфигурацией приложений в Python. Независимо от того какой из них вы выберете, всегда необходимо думать о удобочитаемости файлов конфигурации, дальнейшей их поддержки, а также способах обнаружения ошибок для случаев их некорректного использования. Таким образом, конфигурационный файл – это по сути еще один тип кода.
Надеюсь, вам понравится эта статья, не стесняйтесь оставлять свои комментарии ниже.
Конфигурационные файлы в Python
В этой статье, я хочу попробовать найти идеальный (вероятнее всего) способ хранения и использования конфигурационных файлов в Python. Ну, а также поделиться своей библиотекой для них 
Попытка №1
А что насчёт того чтобы хранить конфигурацию в коде? Ну, а что, вроде удобно, да и новых языков не придётся изучать. Существует множество проектов, в которых данный способ используется, и хочу сказать, вполне успешно.
Типичный конфиг в этом стиле выглядит так:
Да и вообще, почему хоть какие-то данные хранятся в коде? Как мне кажется код, он на то и код, что должен выполнять какую-то логику, а не хранить данные.
Данный подход, на самом деле используется много где. В том же Django. Все думают, что раз это самый популярный фреймворк, который используется в самом Инстаграме, то они то уж плохое советовать не будут. Жаль, что это не так.
Попытка №2
Наш конфиг, который мы уже писали ранее:
А теперь прочитаем в Python:
Попытка №3
А сейчас, я хотел бы показать Вам свою библиотеку, которая призвана решить все эти проблемы (ну, или хотя бы уменьшить ваши страдания :)).
Называется она betterconf и доступна на PyPi.
Установка так же проста, как и любой другой библиотеки:
Изначально, наш конфиг представлен в виде класса с полями:
По умолчанию, библиотека пытается взять значения из переменных окружения, но мы также можем настроить и это:
Из этого примера следует, что мы можем применять различные провайдеры для получения данных. И это действительно иногда бывает удобно, говорю из личного опыта.
Хорошо, а что если у нас в конфигах есть булевые значения, или числа, они же в итоге будут все равно приходить в строках. И для этого есть решение:
Свой кастер написать также легко:
Итоги
Таким образом, мы пришли к выводу, что хранить настройки в исходных кодах — не есть хорошо. Для этого уже придуманы различные форматы. Ну, а вы познакомились с ещё одной полезной (как я считаю :)) библиотекой.
База по языкам программирования: Принцип сохранения функционала
Продолжаю выкладывать выдержки из вводного курса нашей компании по промышленному программированию.
Часть вторая: Принцип сохранения функционала
Рассказывается чем вредны конфиги и почему писать много кода — плохо. Другие части можно найти тут.
Многие языки программирования совмещают как описательный (декларативный) подход для структур данных, так и императивный — для описания операций над данными.
Пример — это C/C++, в котором в файлах заголовка (*.h) декларативным способом описываются структуры данных, функции и методы, а в файлах программы (*.c/*.pp/*.cpp) на императивном языке описываются действия над данными. Другой пример — это PHP, который делится на HTML часть (все *ML языки являются декларативными), описывающий структуру данных для визуализации, и PHP часть, предназначенную для описания действий по заполнению структуры данными.
Важно помнить, что, в общем-то, любой функционал по преобразованию данных можно свести к программе на машине Тьюринга. Неважно, на каком языке и в какой парадигме этот функционал был написан. Таким образом по аналогии с законом сохранения материи Ломоносова-Лувуазье можно ввести закон сохранения функционала.
Сумма функционала программы определяется только разностью источника и стока данных, количество преобразований внутри программы на сумму функционала не влияет.
Фактически, этот закон является одним из переложений третьего начала термодинамики о мере возрастания энтропии. Его можно переформулировать так:
При возрастании количества функционала, количество кода увеличивается.
Этот закон — один из основополагающих для понимании теории программирования. Он задаёт понимание того, что большее количество кода не означает большего количества функционала. Зато большее количество функционала никогда не бывает бесплатным — за возрастание функционала необходимо платить описанием правил перехода, к примеру — строчками кода.
Теорема о программировании на конфигах
Важным следствием этого закона является теорема о программировании на конфигах. Дело в том, что конфиг файл обычно выносят из программы, основываясь о предположении, что при изменении конфиг файла не придётся лезть в программу и менять её код.
При этом зачастую забывается, что любой конфиг-файл по сути своей является не только источником информации, но и декларативным описанием структуры данных, в которую эта информация уложена. По сути, любой конфиг файл — это программа на декларативном ЯП.
Соответственно, добавляя конфиг файл, программист как минимум вносит в программу
а) новый источник данных
б) пишет интерпретатор конфиг-файла
То есть программист добавляет новый функционал в программу (т.к. добавляет ещё один внешний источник данных, а значит в программе необходимо поддержать преобразования данных из этого источника), причём часть этого функционала он описывает на другом, отличном от ЯП на котором делается родительская программа ЯП (собственно, язык конфига).
По закону о сумме функционала, программисту никогда не удастся таким образом создать конфиг, чтобы он полностью снял заботу с пользователя о программировании функционала — часть функционала всегда будет писаться на языке конфига.
Чем больше программа требует конфигов, тем больше пользователю этих конфигов приходится на них программировать. Если же конфиги, при этом, ещё и имеют разный формат заполнения (property-файлы, XML, GUI формы, etc), то пользователю, к тому же, придётся изучить ровно столько новых ЯП, сколько этих конфигов. Это, соответственно, не добавит счастливости пользователю.
Пытаясь сделать программу более функциональной, гибкой к различным ситуациям, вынося настройки во вне системы, программист просто наращивает энтропию материнской программы, создавая новые декларативные ЯП и заставляя пользователя учиться программировать на этих декларативных ЯП.
Не реализуя какой-либо функционал, но давая возможность его включить в конфигах, программист переносит обязанность программировать этот функционал с себя на пользователя программы.
Теорема о простом фреймворке
Одним из следствий теоремы о программировании на конфигах является проблема “гибкого и настраиваемого фреймворка”. Дело в том, что суть любого фреймворка — это предоставление API. API — это, по сути, тоже декларативный язык, описывающий правила использования данного фреймворка. Чем больше раскрыто API, чем больше доступно для этого API параметров, тем более богат этот язык и тем сложнее его изучить, а значит и использовать.
Самый логичный и понятный фреймворк — это фреймворк, предоставляющий минимальный API с максимальным функционалом за ним.
Что такое логичный и понятный фреймворк? Если с помощью фреймворка можно делать одну и ту же вещь несколькими разными способами, это означает что декларативный язык API этого фреймворка является избыточным. Простой фреймворк — это фреймворк, избыточность API которого минимальна.
Теорема о Вавилонском смешении языков
Каждый источник информации, а значит и каждый вид информации требует код, преобразующий этот вид информации к своему внутреннему родному (нативному) представлению. К примеру, конфиг диктует структуру представления информации, API диктует правила вызова. Верно и обратное утверждение, что каждый API, каждый конфиг порождает новый источник информации, которая тоже нуждается в преобразовании вызывающей стороной к нативному виду.
Таким образом, чем больше пар язык-язык используется в программе, чем больше используется структур данных, тем больше программа содержит преобразований. Количество преобразований при этом больше, чем если бы информация поступала в программу с использованием структур данных на базовом для программы ЯП.
Фактически, использование одного дополнительного конфига или дополнительного языка программирования добавляет в программу в два раза больше кода, чем добавление ещё одного источника данных или ещё одной структуры данных, описанной на материнском языке программы.
Чем больше разных языков используется в проекте (включая сюда разные форматы конфигов и разные API), тем больше кода возникает в программе, при сохранении того же функционала.
Собственно, из этого следует теорема о Вавилонском смешении языков:
Добавление фреймворка, конфига или ЯП для облегчения разбора данных приводит к усложнению разбора данных.
У нас с этим непосредственно столкнулись ребята, работающие с функционалом новой корзины — там крутой замес описательной и исполнительной парадигм, представленной в нескольких видах конфигов и использующих несколько видов API.