Как сделать конфигурационный файл python
Добавил пользователь Владимир З. Обновлено: 05.10.2024
Эта статья предназначена для чтения файлов конфигурации, написанных в общем формате файла конфигурации .ini . Модуль configparser может использоваться для чтения файлов конфигурации.
Код № 1: файл конфигурации
; Sample configuration file
library = % (prefix)s / lib
include = % (prefix)s / include
bin = % (prefix)s / bin
prefix = / usr / local
pid - file = / tmp / spam.pid
root = / www / root
Код № 2: чтение файла и извлечение значений.
from configparser import ConfigParser
print (configur.read( 'config.ini' ))
print ( "Sections : " , configur.sections())
print ( "Installation Library : " , configur.get( 'installation' , 'library' ))
print ( "Log Errors debugged ? : " , configur.getboolean( 'debug' , 'log_errors' ))
print ( "Port Server : " , configur.getint( 'server' , 'port' ))
print ( "Worker Server : " , configur.getint( 'server' , 'nworkers' ))
Выход :
Можно также изменить конфигурацию и записать ее обратно в файл, используя метод cfg.write() .
Код № 3:
configur. set ( 'server' , 'port' , '9000' )
configur. set ( 'debug' , 'log_errors' , 'False' )
Выход :
Имена, используемые в файле конфигурации, также считаются без учета регистра, как показано в коде ниже —
configur.get( 'installation' , 'PREFIX' )
configur.get( 'installation' , 'prefix' )
Выход :
При разборе значений такие методы, как getboolean (), ищут любое разумное значение. Например, все они эквивалентны.
Наиболее примечательный контраст между записью конфигурации и кодом Python заключается в том, что, в отличие от сценариев, файлы конфигурации не выполняются сверху вниз. Скорее файл читается полностью. На случай, если переменные замены сделаны, они сделаны позже после факта. Например, не имеет значения, что префиксная переменная размещается после разных переменных, которые ее используют.
Несколько файлов конфигурации могут быть прочитаны вместе, и их результаты могут быть объединены в одну конфигурацию с помощью ConfigParser, что делает его таким особенным в использовании.
Пример — пользователь сделал свой собственный файл конфигурации, который выглядит как.
Этот файл можно объединить с предыдущей конфигурацией, прочитав его отдельно
Приложения требуют настройки. Здесь описаны различные настройки, которые можно менять в зависимости от окружения, в котором работает приложение: переключение режима отладки, настройки секретного ключа и т.п.
Flask спроектирован так, что обычно требует настройки при запуске приложения. Вы можете вшить настройки в код, что не так уж плохо для многих небольших приложений, но имеются способы лучше.
Вне зависимости от того, каким образом загружена конфигурация, существует объект конфигурации, содержащий загруженные параметры: атрибут config объекта Flask . Это место, где Flask содержит свои настройки, а также то место, куда расширения могут поместить собственные настройки. Но здесь можно размещать и конфигурацию вашего приложения.
Основы конфигурации¶
config на самом деле является подклассом словаря и может изменяться точно так же, как и любой словарь:
Некоторые параметры конфигурации передаются в объект Flask , которые тоже можно читать и писать:
Для обновления нескольких ключей за раз можно воспользоваться методом словаря dict.update() :
Встроенные параметры конфигурации¶
Сам Flask использует следующие параметры конфигурации:
Подробнее о SERVER_NAME
SERVER_NAME - это параметр, который используется для поддержки поддоменов. Flask не может догадаться о том, какая часть доменного имени является поддоменом, не зная имя сервера. Этот же параметр используется для настройки переменной браузера, в которой хранится сеанс.
Помните, что не только Flask не может узнать поддомен, ваш веб-браузер тоже не может. Большинство соверменных браузеров не разрешают междоменные переменные браузера, если в имени сервера нет точек. Поэтому если имя сервера 'localhost' , вы не сможете задать переменную браузера для 'localhost' и каждого из его поддоменов. В этом случае выберите другое имя сервера, например 'myapplication.local' и добавьте это имя и поддомены, которые вы хотите использовать, в файл hosts или настройте локальный bind.
Задание конфигурации с помощью файлов¶
Конфигурация становится более удобной, если разместить её в отдельном файле. Лучше, если он находится за пределами пакета с приложением. Это позволяет создавать пакеты и распространять приложения с помощью различных инструментов обработки пакетов ( distribute-deployment ) и впоследствии - изменять конфигурацию.
Далее показан обычный пример::
Сначала грузится конфигурация из модуля yourapplication.default_settings , а затем её значения заменяет содержимое файла, указанного в переменной окружения YOURAPPLICATION_SETTINGS . Эта переменная окружения может быть задана в Linux или OS X при помощи команды export оболочки перед запуском сервера:
В системах Windows воспользуйтесь встроенной командой set :
Файлы конфигурации являются обычными файлами Python. В объект конфигурации сохраняются только переменные с именами в верхнем регистре, так что убедитесь в том, что имена ваших параметров заданы в верхнем регистре.
Вот пример файла конфигурации:
Убедитесь в том, что файл загружается как можно раньше, чтобы расширения могли получить доступ к собственным настройкам при запуске. Существуют другие методы загрузки объекта конфигурации из отдельных файлов. За более полной информацией обратитесь к документации объекта Config .
Лучшие способы задания конфигурации¶
Недостаток описанного выше подхода заключается в усложнении тестирования. Нет стопроцентного способа решения этой проблемы, но вот несколько рекомендаций опытных пользователей:
- Создайте ваше приложение внутри функции и зарегистрируйте в ней blueprint’ы. Таким образом вы можете создать несколько экземпляров вашего приложения с разными конфигурациями, что значительно упростит модульное тестирование. Вы можете воспользоваться функцией, чтобы передать в неё необходимую конфигурацию.
- Не пишите код, которому требуется конфигурация при импорте. Если ограничиться чтением конфигурации по запросу, возможно будет переконфигурировать объект позже.
Режим разработки и режим эксплуатации¶
Большинству приложений нужно более одной конфигурации. По меньшей мере нужна отдельная конфигурация для рабочего сервера и ещё одна для разработки. Простейший способ управления ими - это создать конфигурацию по умолчанию, которая загружается всегда и которую можно поместить в систему управления версиями, и частичные конфигурации, которые заменяют необходимые значения следующим образом:
Теперь просто создайте отдельный файл config.py , выполните команду export YOURAPPLICATION_SETTINGS=/path/to/config.py и готово. Однако, существуют альтернативные способы. Например, можно воспользоваться импортом и подклассами.
В мире Django распространён следующий способ: сделать явный импорт конфигурации, добавив строку from yourapplication.default_settings import * в начале файла, а затем заменить значения вручную. Можно сделать также, затем взять из переменной окружения вида YOURAPPLICATION_MODE необходимый режим - production , development и т.п., а затем импортировать заранее определённые файлы, основываясь на этом значении.
Другой любопытный способ - воспользоваться классами и наследованием конфигурации:
Для включения такой конфигурации, вам просто нужно вызвать from_object() :
Есть много разных способов, которые можно выбрать для управления файлами конфигурации. Вот список хороших советов:
- Храните файл конфигурации по умолчанию в системе управления версиями. Заполните объект конфигурации значениями по умолчанию или импортируйте его в ваших собственных файлах конфигурации перед тем, как заменить значения.
- Воспользуйтесь переменной окружения для переключения между конфигурациями. Это можно сделать вне интерпретатора Python и это позволит упростить разработку и развёртывание, потому что вы можете быстро и легко переключаться между разными конфигурациями, совсем не прикасаясь к коду. Если вы часто работаете над разными проектами, можно создать собственный скрипт, который будет определять текущий каталог проекта, активировать virtualenv и экспортировать конфигурацию режима разработки.
- Используйте инструмент fabric для внесения изменений на сервер эксплуатации и раздельных конфигураций на серверы эксплуатации. За более подробным описанием того, как это сделать, обратитесь к главе fabric-deployment .
Каталоги экземпляров¶
Во Flask 0.8 появились каталоги экземпляров. Flask долгое время позволял ссылаться на пути относительно каталога приложения (с помощью Flask.root_path ). Поэтому многие разработчики хранили конфигурацию рядом с приложением. К несчастью, это возможно только если приложение не находится внутри пакета, так как в таком случае root_path указывает внутрь пакета.
Во Flask 0.8 был введён новый атрибут: Flask.instance_path . Он вводит новое понятие, которое называется “каталогом экземпляра”. Каталог экземпляра задуман как каталог, не управляемый системой контроля версий и относящийся к развёрнутому приложению. Это подходящее место для того, чтобы поместить в него файлы, изменяемые в процессе работы или файлы конфигурации.
Можно явным образом указать путь к каталогу экземпляра при создании приложения Flask или можно разрешить Flask’у самому выбрать каталог экземпляра. Чтобы задать его явным образом, воспользуйтесь параметром instance_path :
Помните, что если этот путь указан, он должен быть абсолютным.
Если параметр instance_path не указан, по умолчанию используются следующие места:
Python — замечательный язык программирования и многое другое. Одним из его слабых мест является упаковка. Это общеизвестный факт в сообществе. Установка, импорт, использование и создание пакетов с годами улучшились, но они все еще не соответствуют новым языкам, таким как Go и Rust, которые могли бы многому научиться из борьбы Python и других более зрелых языков.
Упаковка проекта
Упаковка проекта — это процесс, с помощью которого вы берете согласованный набор модулей Python и, возможно, другие файлы и помещаете их в структуру, которую можно легко использовать. Есть несколько вещей, которые вы должны учитывать, такие как зависимости от других пакетов, внутренняя структура (подпакеты), управление версиями, целевая аудитория и форма пакета (исходный и / или двоичный).
пример
Давайте начнем с быстрого примера. Пакет conman — это пакет для управления конфигурацией. Он поддерживает несколько форматов файлов, а также распределенную конфигурацию с использованием etcd .
Содержимое пакета, как правило, хранится в одном каталоге (хотя распространено разделение подпакетов в нескольких каталогах), а иногда, как в этом случае, в его собственном git-репозитории.
Давайте быстро взглянем на файл setup.py . Он импортирует две функции из пакета setuptools : setup() и find_packages() . Затем он вызывает функцию setup() и использует find_packages() для одного из параметров.
Это довольно нормально. Хотя файл setup.py является обычным файлом Python, и вы можете в нем делать все, что захотите, его основная задача — вызывать функцию setup() с соответствующими параметрами, поскольку при установке он будет вызываться различными инструментами стандартным способом. ваш пакет Я расскажу подробности в следующем разделе.
Файлы конфигурации
В дополнение к setup.py , есть несколько других необязательных файлов конфигурации, которые могут отображаться здесь и использоваться для различных целей.
Setup.py
Функция setup() принимает большое количество именованных аргументов для управления многими аспектами установки пакета, а также выполнения различных команд. Многие аргументы указывают метаданные, используемые для поиска и фильтрации при загрузке вашего пакета в хранилище.
- name: название вашего пакета (и как оно будет указано в PYPI)
- версия: это важно для правильного управления зависимостями
- url: URL вашего пакета, обычно GitHub или, возможно, URL readthedocs
- пакеты: список подпакетов, которые должны быть включены; find_packages() помогает здесь
- setup_requires: здесь вы указываете зависимости
- test_suite: какой инструмент запустить во время теста
long_description задается здесь как содержимое файла README.md , что является наилучшей практикой, чтобы иметь единый источник правды.
setup.cfg
Файл setup.py также служит интерфейсом командной строки для запуска различных команд. Например, чтобы запустить модульные тесты, вы можете набрать: python setup.py test
Setup.cfg — это файл в формате ini, который может содержать значения по умолчанию для команд, которые вы передаете в setup.py . Здесь setup.cfg содержит несколько опций для nosetests (наш тестовый бегун):
MANIFEST.in
Этот файл содержит файлы, которые не являются частью внутренней директории пакета, но вы все еще хотите включить. Это, как правило, файл readme файл лицензии и тому подобное. Важным файлом является файл requirements.txt . Этот файл используется pip для установки других необходимых пакетов.
Вот файл MANIFEST.in Конмана:
зависимости
Вы можете указать зависимости как в разделе install_requires файла setup.py и в файле require.txt. Pip автоматически установит зависимости из install_requires , но не из файла needs.txt. Чтобы установить эти требования, вы должны будете явно указать их при запуске pip: pip install -r requirements.txt .
Опция install_requires предназначена для указания минимальных и более абстрактных требований на уровне основной версии. Файл needs.txt предназначен для более конкретных требований, часто с закрепленными второстепенными версиями.
Вот файл требований conman. Вы можете видеть, что все версии закреплены, что означает, что на него может быть оказано негативное влияние, если один из этих пакетов обновится и внесет изменение, нарушающее конман.
Закрепление дает вам предсказуемость и душевное спокойствие. Это особенно важно, если многие люди устанавливают ваш пакет в разное время. Без закрепления, каждый человек получит различное сочетание версий зависимостей в зависимости от того, когда они его установили. Недостатком закрепления является то, что если вы не успеваете за развитием зависимостей, вы можете застрять в старой, плохо работающей и даже уязвимой версии зависимости.
Первоначально я написал conman в 2014 году и не обращал на это особого внимания. Теперь, для этого урока, я обновил все, и было несколько серьезных улучшений для почти каждой зависимости.
Распределения
Вы можете создать исходный дистрибутив или бинарный дистрибутив. Я покрою оба.
Распределение источников
Вы создаете исходный дистрибутив с помощью команды: python setup.py sdist . Вот вывод для conman:
Для установки этого пакета потребуется этап сборки (даже если это чистый Python). Вы можете установить его с помощью pip как обычно, просто передав путь к пакету. Например:
Conman был установлен в site-пакеты и может быть импортирован как любой другой пакет:
Колеса
Колеса — это относительно новый способ упаковки кода Python и, возможно, расширений C. Они заменяют формат яйца. Существует несколько типов колес: колеса чистого Python, колеса платформы и универсальные колеса. Чистые колеса Python — это пакеты типа conman, которые не имеют кода расширения C.
Колеса платформы имеют код расширения C. Универсальные колеса — это чистые колеса Python, которые совместимы как с Python 2, так и с Python 3 с одинаковой кодовой базой (для них не требуется даже 2to3). Если у вас есть чистый пакет Python и вы хотите, чтобы ваш пакет поддерживал как Python 2, так и Python 3 (что становится все более и более важным), то вы можете собрать одну универсальную сборку вместо одного колеса для Python 2 и одного колеса для Python 3.
Если ваш пакет имеет код расширения C, вы должны создать колесо платформы для каждой платформы. Огромное преимущество колес, особенно для пакетов с расширениями C, заключается в том, что нет необходимости иметь компилятор и вспомогательные библиотеки, доступные на целевой машине. Колесо уже содержит встроенный пакет. Таким образом, вы знаете, что его не удастся собрать, и установить его намного быстрее, потому что это буквально просто копия. Люди, которые используют научные библиотеки, такие как Numpy и Pandas, могут по достоинству оценить это, поскольку установка таких пакетов занимала много времени и могла привести к сбою, если какая-то библиотека отсутствовала или компилятор не был правильно настроен.
Команда для создания чистых колес или платформ: python setup.py bdist_wheel .
Setuptools — движок, который обеспечивает функцию setup() — автоматически обнаружит, нужно ли чистое колесо или колесо платформы.
А принципы организации и разделения config-файлов какие можете назвать?
1. Иерархический (древовидный) - xml
2. Список списков ([section] name=value) - ini
3. Простой список (name=value) - txt
.
Какие недостатки имеет модуль ConfigParser?
Если не предполагается редактировать конфиг руками, то можно заюзать pickle или аналоги.
Если предполагается - можно заюзать execfile или import. Это же питон;-)
Организация зависит от задачи. У меня обычно словарь - в эту идеологию лезет фсе.
У меня обычно словарь - в эту идеологию лезет фсе.
Ok. Поскольку я делаю opensource-приложение, это наверное будет самым эффективным. Просто import config :) Я про него что-то забыл :)
Странно, обычно в программах на динамических языках конфиг - просто скрипт на том же языке. Зачем создавать парсеры, если может распарсить интерпретатор?
в новых программах стараюсь использовать yaml. в отличие от xml, он человекоредактируемый.
эх. сделали бы давно хоть какой-нибудь стандарт и убрали бы помойку в /etc.
эх. сделали бы давно хоть какой-нибудь стандарт и убрали бы помойку в /etc.
Этих стандартов уже давно сделали как грязи. Выбирай любой.
Организовать в виде .py-модуля. Формат хранения от словаря до каскада вложенных кортежей. xml и прочие костыли-то зачем тянуть в проект?
Если предполагается - можно заюзать execfile или import. Это же питон;-)
Зачем создавать парсеры, если может распарсить интерпретатор?
Только чем он лучше конфигпарсер? :)
Тем что отсутствие запятой в конфиге угробит весь конфиг?
Да и программа может менять конфиг, а это с питонячим кодом будет фиговато.
Тред не читал, люблю этот.
Нет дурацких секций, есть типизация и сложные значения (списки и словари).
Читайте также: