> **Источник:** https://python-all.ru/3.1/distutils/configfile.html
>
> «Документация Python на русском» – неофициальный перевод официальной документации Python: версии от 2.6 до 3.16, полнотекстовый поиск, английский оригинал рядом с переводом. Эта Markdown-версия страницы предназначена для работы с LLM: вставьте её в ChatGPT, Claude или Cursor.

---

# 3. Создание файла конфигурации установки

Часто невозможно *заранее* описать всё необходимое для сборки дистрибутива: для продолжения может потребоваться получить информацию от пользователя или от его системы. Если эта информация достаточно проста – например, список каталогов для поиска C-заголовков или библиотек, – то предоставление конфигурационного файла `setup.cfg` для редактирования пользователями является простым и недорогим способом её запросить. Конфигурационные файлы также позволяют задавать значения по умолчанию для любых опций команд, которые установщик затем может переопределить либо в командной строке, либо отредактировав конфигурационный файл.

Конфигурационный файл setup является полезной серединой между сценарием setup – который, в идеале, должен быть непрозрачным для установщиков [\[1\]](https://python-all.ru/3.1/distutils/configfile.html#id2) – и командной строкой сценария setup, которая находится вне вашего контроля и полностью зависит от установщика. Фактически, `setup.cfg` (и любые другие конфигурационные файлы Distutils, присутствующие в целевой системе) обрабатываются после содержимого сценария setup, но до командной строки. Это даёт несколько полезных следствий:

- установщики могут переопределить часть того, что вы задали в `setup.py`, отредактировав `setup.cfg`
- вы можете задавать нестандартные значения по умолчанию для опций, которые сложно установить в `setup.py`
- установщики могут переопределить что угодно в `setup.cfg`, используя опции командной строки `setup.py`

Базовый синтаксис файла конфигурации прост:

```python
[command]
option=value
...
```

где *command* – одна из команд Distutils (например, **build\_py**, **install**), а *option* – один из параметров, поддерживаемых этой командой. Для каждой команды можно указать любое количество параметров, и в файл можно включить любое количество секций команд. Пустые строки игнорируются, как и комментарии, которые начинаются с символа `'#'` и продолжаются до конца строки. Длинные значения параметров можно разбивать на несколько строк, просто делая отступы для строк продолжения.

Список опций, поддерживаемых конкретной командой, можно узнать с помощью универсальной опции *--help*, например,

```python
> python setup.py --help build_ext
[...]
Options for 'build_ext' command:
  --build-lib (-b)     directory for compiled extension modules
  --build-temp (-t)    directory for temporary files (build by-products)
  --inplace (-i)       ignore build-lib and put compiled extensions into the
                       source directory alongside your pure Python modules
  --include-dirs (-I)  list of directories to search for header files
  --define (-D)        C preprocessor macros to define
  --undef (-U)         C preprocessor macros to undefine
  --swig-opts          list of SWIG command line options
[...]
```

Обратите внимание, что параметр, записываемый в командной строке как *--foo-bar*, в файлах конфигурации записывается как *foo\_bar*.

Например, предположим, вы хотите, чтобы ваши расширения собирались «на месте» – то есть у вас есть расширение `pkg.ext`, и вы хотите, чтобы скомпилированный файл расширения (скажем, `ext.so` в Unix) был помещён в тот же исходный каталог, что и ваши чистые модули Python `pkg.mod1` и `pkg.mod2`. Для этого всегда можно использовать опцию *--inplace* в командной строке:

```python
python setup.py build_ext --inplace
```

Но это требует, чтобы вы всегда явно указывали команду **build\_ext** и не забывали передавать *--inplace*. Более простой способ – «установить и забыть» эту опцию, закодировав её в `setup.cfg`, конфигурационном файле этого дистрибутива:

```python
[build_ext]
inplace=1
```

Это повлияет на все сборки данного дистрибутива модуля, независимо от того, указываете ли вы явно **build\_ext**. Если вы включите `setup.cfg` в свой дистрибутив исходного кода, это также повлияет на сборки конечных пользователей – что, вероятно, плохая идея для этой опции, поскольку постоянная сборка расширений на месте нарушит установку дистрибутива модуля. В некоторых особых случаях, однако, модули собираются прямо в каталоге установки, так что это, возможно, полезная возможность. (Хотя распространять расширения, которые ожидают сборки в своём каталоге установки, почти всегда плохая идея.)

Другой пример: некоторые команды принимают много опций, которые не меняются от запуска к запуску; например, **bdist\_rpm** нужно знать всё необходимое для создания файла «spec» для формирования RPM-дистрибутива. Часть этой информации берётся из сценария setup, а часть генерируется автоматически Distutils (например, список устанавливаемых файлов). Но некоторую информацию необходимо передавать в качестве опций **bdist\_rpm**, что было бы очень утомительно делать в командной строке при каждом запуске. Поэтому вот фрагмент из собственного `setup.cfg` пакета Distutils:

```python
[bdist_rpm]
release = 1
packager = Greg Ward <gward@python.net>
doc_files = CHANGES.txt
            README.txt
            USAGE.txt
            doc/
            examples/
```

Обратите внимание: параметр *doc\_files* – это просто строка, разделённая пробельными символами, разбитая на несколько строк для удобочитаемости.

> **См. также**
>
> **[*Синтаксис файлов конфигурации*](https://python-all.ru/3.1/install/index.html#inst-config-syntax) в «Installing Python Modules»**
>
> Дополнительная информация о файлах конфигурации доступна в руководстве для системных администраторов.

Сноски

| [\[1\]](https://python-all.ru/3.1/distutils/configfile.html#id1) | Этот идеал, вероятно, не будет достигнут до тех пор, пока автонастройка не будет полностью поддерживаться в Distutils. |
| --- | --- |