Ошибка модуля файла Ini

Обновлено: 21.11.2024

Mypy поддерживает чтение параметров конфигурации из файла. По умолчанию используется файл mypy.ini с откатом к .mypy.ini, затем pyproject.toml, затем setup.cfg в текущем каталоге, затем $XDG_CONFIG_HOME/mypy/config, затем ~/.config/mypy/config, и, наконец, .mypy.ini в домашнем каталоге пользователя, если ни один из них не найден; вместо этого можно использовать флаг командной строки --config-file для чтения другого файла (см. Файл конфигурации ).

Важно понимать, что слияния файлов конфигурации не происходит, так как это может привести к неоднозначности. Флаг --config-file имеет наивысший приоритет и должен быть правильным; в противном случае mypy сообщит об ошибке и завершит работу. Без параметра командной строки mypy будет искать файлы конфигурации в указанном выше порядке.

Большинство флагов близко соответствуют флагам командной строки, но есть некоторые различия в именах флагов, и некоторые флаги могут принимать разные значения в зависимости от обрабатываемого модуля.

Некоторые флаги поддерживают расширение домашнего каталога пользователя и переменной среды. Чтобы обратиться к домашнему каталогу пользователя, используйте ~ в начале пути. Чтобы расширить переменные среды, используйте $VARNAME или $ .

Формат файла конфигурации¶

Должен присутствовать раздел с именем [mypy]. Это определяет глобальные флаги.

Дополнительные разделы с именами [mypy-PATTERN1,PATTERN2. ] может присутствовать, где ШАБЛОН1 , ШАБЛОН2 и т. д. — это шаблоны полных имен модулей, разделенных запятыми, с некоторыми компонентами, которые можно заменить символом '*' (например, foo.bar , foo.bar.* , foo. *.баз ). В этих разделах указаны дополнительные флаги, которые применяются только к модулям, имя которых соответствует хотя бы одному из шаблонов.

Шаблон в форме квалифицированное_имя_модуля соответствует только именованному модулю, тогда как точка_имя_модуля.* соответствует имени_модуля и любым подмодулям (так что foo.bar.* будет соответствовать всем foo.bar , foo.bar.baz и foo.bar. baz.quux ).

Шаблоны также могут быть «неструктурированными» подстановочными знаками, в которых звезды могут появляться в середине имени (например, site.*.migrations.* ). Звездочки соответствуют нулю или более компонентам модуля (поэтому site.*.migrations.* может соответствовать site.migrations ).

Когда параметры конфликтуют, приоритет конфигурации следующий:

  1. Встроенная конфигурация в исходном файле

  2. Секции с конкретными именами модулей ( foo.bar )

  3. Разделы с «неструктурированными» шаблонами подстановочных знаков ( foo.*.baz ), при этом разделы, расположенные позже в файле конфигурации, переопределяют предыдущие разделы.

  4. Разделы с «хорошо структурированными» шаблонами подстановочных знаков ( foo.bar.* ), с более конкретным переопределением более общего.

  5. Параметры командной строки.

  6. Параметры файла конфигурации верхнего уровня.

Различие в порядке приоритета между «структурированными» шаблонами (по специфичности) и «неструктурированными» шаблонами (по порядку в файле) является неудачным и может быть изменено в будущих версиях.

Флаг warn_unused_configs может быть полезен для устранения ошибок в именах разделов.

Флаги конфигурации могут меняться между выпусками.

Модульные и глобальные параметры¶

Некоторые параметры конфигурации могут быть установлены либо глобально (в разделе [mypy]), либо для каждого модуля (в таких разделах, как [mypy-foo.bar]).

Если вы устанавливаете параметр как глобально, так и для определенного модуля, параметры конфигурации модуля имеют приоритет. Это позволяет вам устанавливать глобальные значения по умолчанию и переопределять их для каждого модуля. Если модулю соответствуют несколько разделов шаблона, в тех случаях, когда они не совпадают, используются параметры из наиболее конкретного раздела.

Некоторые другие параметры, как указано в их описании, могут быть установлены только в глобальном разделе ( [mypy] ).

Инвертирование значений параметров¶

Параметры, принимающие логическое значение, можно инвертировать, добавив к их имени no_ или (если применимо) заменив их префикс с disallow на allow (и наоборот).

Примеры¶

Вот пример файла mypy.ini. Чтобы использовать этот файл конфигурации, поместите его в корень репозитория и запустите mypy.

В этом файле конфигурации указаны три глобальных параметра в разделе [mypy]. Эти три варианта:

Проверьте тип всего проекта, предполагая, что он будет выполняться с использованием Python 2.7. (Это эквивалентно использованию флага --python-version 2.7 или -2).

Сообщать об ошибке всякий раз, когда функция возвращает значение, предположительно имеющее тип Any .

Сообщайте обо всех параметрах конфигурации, которые не используются mypy. (Это поможет нам выявить опечатки при внесении изменений в наш файл конфигурации).

Далее этот модуль определяет три параметра для каждого модуля. Первые два параметра изменяют способ проверки mypy type кода в mycode.foo.* и mycode.bar , которые, как мы предполагаем, являются двумя написанными вами модулями. Последняя опция конфигурации изменяет то, как mypy type проверяет somelibrary, которая, как мы предполагаем, является какой-то сторонней библиотекой, которую вы установили и импортируете. Эти параметры будут:

Выборочно запрещать нетипизированные определения функций только в пакете mycode.foo, то есть только для определений функций, определенных в каталоге mycode/foo.

Выборочно отключите предупреждения «функция возвращает какие-либо» только в mycode.bar. Это переопределяет глобальное значение по умолчанию, которое мы установили ранее.

Подавление любых сообщений об ошибках, возникающих, когда ваша кодовая база пытается импортировать модуль somelibrary . Это полезно, если в какой-то сторонней библиотеке отсутствуют подсказки типа.

Импорт обнаружения¶

Дополнительную информацию см. в разделе "Обнаружение импорта" документации по командной строке.

Указывает пути для использования после попытки пути из переменной среды MYPYPATH. Полезно, если вы хотите сохранить заглушки в своем репо вместе с файлом конфигурации. Несколько путей всегда разделяются : или , независимо от платформы. Домашний каталог пользователя и переменные среды будут расширены.

Относительные пути обрабатываются относительно рабочего каталога команды mypy, а не файла конфигурации. Используйте переменную среды MYPY_CONFIG_FILE_DIR для ссылки на пути относительно файла конфигурации (например, mypy_path = $MYPY_CONFIG_FILE_DIR/src ).

Этот параметр можно установить только в глобальном разделе ( [mypy] ).

Примечание. В Windows используйте пути UNC, чтобы избежать использования : (например, \\127.0.0.1\X$\MyDir, где X — буква диска).

список строк, разделенных запятыми

Список путей, разделенных запятыми, который должен проверяться mypy, если ни один из них не указан в командной строке. Поддерживает рекурсивную подстановку файлов с использованием glob , где * (например, *.py ) соответствует файлам в текущем каталоге, а **/ (например, **/*.py ) соответствует файлам в любых каталогах ниже текущего. Домашний каталог пользователя и переменные среды будут расширены.

Этот параметр можно установить только в глобальном разделе ( [mypy] ).

Регулярное выражение, которое соответствует именам файлов, именам каталогов и путям, которые mypy должен игнорировать при рекурсивном обнаружении файлов для проверки. Используйте косую черту ( / ) в качестве разделителей каталогов на всех платформах.

Создание единого регулярного выражения, которое исключает несколько файлов, но при этом остается удобочитаемым, может оказаться непростой задачей. Приведенный выше пример демонстрирует один из подходов. (?x) включает флаг VERBOSE для последующего регулярного выражения, которое игнорирует большинство пробелов и поддерживает комментарии. Вышеприведенное эквивалентно: (^one\.py$|two\.pyi$|^three\.) .

Подробнее см. --exclude .

Этот параметр можно установить только в глобальном разделе ( [mypy] ).

Обратите внимание, что эквивалент TOML немного отличается. Это может быть либо одна строка (в том числе многострочная), которая обрабатывается как одно регулярное выражение, либо массив таких строк. Следующие примеры TOML эквивалентны приведенному выше примеру INI.

Этот подключаемый модуль является частью коллекции community.general (версия 4.2.0).

Возможно, у вас уже установлена ​​эта коллекция, если вы используете пакет ansible. Он не включен в ansible-core. Чтобы проверить, установлен ли он, запустите ansible-galaxy collection list .

Чтобы установить его, используйте: ansible-galaxy collection install community.general .

Чтобы использовать его в плейбуке, укажите: community.general.ini_file .

Краткий обзор

Управление (добавление, удаление, изменение) отдельными параметрами в файле в стиле INI без необходимости управления файлом в целом с помощью, например, ansible.builtin.template или ansible.builtin.assemble .

Добавляет отсутствующие разделы, если они не существуют.

До Ansible 2.0 комментарии отбрасывались при чтении исходного файла и поэтому не отображались в целевом файле.

Начиная с Ansible 2.3, этот модуль добавляет отсутствующие конечные символы новой строки в файлы, чтобы соответствовать стандарту POSIX, даже если не требуется никаких других изменений.

Параметры

Создайте файл резервной копии, включив в него информацию о временной метке, чтобы вы могли вернуть исходный файл, если вы каким-то образом стерли его неправильно.

Если задано значение "да" (по умолчанию), все совпадающие строки option удаляются, когда state=отсутствует, или заменяются, когда state=present.

Если установлено значение no , только указанные значения добавляются, когда state=present, или удаляются, когда state=отсутствует, а существующие не изменяются.

Для тех, кто привык к /usr/bin/chmod, помните, что режимы на самом деле представляют собой восьмеричные числа. Вы должны либо добавить начальный ноль, чтобы синтаксический анализатор Ansible YAML знал, что это восьмеричное число (например, 0644 или 01777), либо заключить его в кавычки (например, «644» или «1777»), чтобы Ansible получил строку и мог выполнить собственное преобразование из строки. в число.

Предоставление Ansible числа без соблюдения одного из этих правил приведет к получению десятичного числа, что приведет к неожиданным результатам.

Начиная с Ansible 1.8, режим может быть указан как символьный режим (например, u+rwx или u=rw,g=r,o=r ).

Если режим не указан и целевой объект файловой системы не существует, при установке режима для вновь созданного объекта файловой системы будет использоваться umask по умолчанию в системе.

Если режим не указан, а целевой объект файловой системы существует, будет использоваться режим существующего объекта файловой системы.

Указание режима — лучший способ убедиться, что объекты файловой системы создаются с правильными разрешениями. Дополнительные сведения см. в CVE-2020-1736.

Я использую Ansible для создания файлов конфигурации в формате ini. Когда я использую модуль ini_file с парой параметров и значений, он работает, как и ожидалось, например:

В результате будет:

Однако я хочу, чтобы определенный раздел существовал без опций, например так:

Но все, что он делает, это сообщает об успешном выполнении задачи и переходит к следующей.

Как я могу использовать модуль для создания разделов без параметров?

3 ответа 3

ini — это неформальный стандарт, но, насколько я понимаю, раздел без опций не имеет особого смысла. Это было бы моим первым предположением, почему это не реализовано в Ansible.

Вместо использования ini -Module я бы предложил использовать модуль lineinfile, чтобы убедиться, что раздел присутствует в ini-файле.

Мое приложение использует эти разделы для определения некоторых вещей во время загрузки (например, для прослушивания портов), а параметры предназначены для дополнительных параметров конфигурации. Я уверен, что мое приложение не единственное, в котором используются разделы без параметров.

Для создания файлов конфигурации используйте шаблоны, это правильный путь. Используйте модуль ini_file только для редактирования файлов. Старайтесь избегать модуля lineinfile, используйте его в крайнем случае.

правило 0) Если возможно, используйте модуль шаблона, он дает вам полный контроль и проверку. Брайан Кока (старший инженер-программист, Ansible, Red Hat)

Проблема с использованием модуля шаблона в моем случае заключается в том, что он перезаписывает целевой файл конфигурации каждый раз, когда я запускаю игру.

Я не упомянул, что мое приложение может перезаписывать и изменять файлы конфигурации как при запуске, так и на лету. Я использую шаблон в нескольких местах, где могу, но для некоторых файлов (например, обсуждаемого) в моем случае это неизбежно.

Пожалуйста, уточните свой вопрос. Изначально вы сказали, что используете ansible для создания конфигурационных файлов в формате ini. Теперь похоже, что вы хотите редактировать ini-файлы с помощью ansible. Пожалуйста, измените свой вопрос, чтобы охватить ваш случай, потому что на первоначальный вопрос вы уже получили ответ.

Читайте также: