# 3. Escrevendo o arquivo de configuração de instalação

Nota

Este documento está sendo mantido apenas até que a documentação do `setuptools` em https://setuptools.readthedocs.io/en/latest/setuptools.html cubra independentemente todas as informações relevantes atualmente incluídas aqui.

Frequentemente, não é possível escrever tudo o que é necessário para construir uma distribuição a priori: você pode precisar obter algumas informações do usuário, ou do sistema do usuário, para prosseguir. Contanto que essa informação seja bastante simples – uma lista de diretórios para pesquisar arquivos de cabeçalho C ou bibliotecas, por exemplo – então fornecer um arquivo de configuração, `setup.cfg`, para os usuários editarem é um maneira pouco custosa e fácil de solicitá-la. Os arquivos de configuração também permitem fornecer valores padrão para qualquer opção de comando, que o instalador pode então substituir na linha de comando ou editando o arquivo de configuração.

O arquivo de configuração de instalação é um meio-termo útil entre o script de instalação – que, idealmente, deveria ser utilizado sem que os instaladores se preocupem com seu conteúdo [1] – e a linha de comando para o script de instalação, que está fora do seu controle e inteiramente a cargo do instalador. Na verdade, `setup.cfg` (e quaisquer outros arquivos de configuração Distutils presentes no sistema de destino) são processados após o conteúdo do script de instalação, mas antes da linha de comando. Isso tem várias consequências úteis:

- os instaladores podem substituir parte do que você colocou em `setup.py` editando `setup.cfg`

- você pode fornecer valores iniciais fora do padrão para opções que não são facilmente definidas em `setup.py`

- os instaladores podem substituir qualquer coisa em `setup.cfg` usando as opções de linha de comando para `setup.py`

A sintaxe básica do arquivo de configuração é simples:

    [command]
    option=value
    ...

sendo command um dos comandos Distutils (por exemplo build_py, install) e option uma das opções as quais o comando tem suporte. Qualquer número de opções pode ser fornecido para cada comando e qualquer número de seções de comando pode ser incluído no arquivo. As linhas em branco são ignoradas, assim como os comentários, que vão de um caractere `'#'` até o final da linha. Valores de opção longas podem ser divididos em várias linhas simplesmente indentando as linhas de continuação.

Você pode descobrir a lista de opções suportadas por um comando específico com a opção universal `--help`, por exemplo.

    $ 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
    [...]

Note que uma opção escrita `--foo-bar` na linha de comando é escrita `foo_bar` nos arquivos de configuração.

Por exemplo, digamos que você queira que suas extensões sejam construídas “localmente” – isto é, você tem uma extensão `pkg.ext`, e deseja o arquivo de extensão compilado (`ext.so` no Unix, digamos) para serem colocados no mesmo diretório fonte de seus módulos Python puros `pkg.mod1` e `pkg.mod2`. Você sempre pode usar a opção `--inplace` na linha de comando para garantir isso:

    python setup.py build_ext --inplace

Mas isso requer que você sempre especifique o comando build_ext explicitamente, e que lembre-se de fornecer `--inplace`. Uma maneira mais fácil é “definir e esquecer” esta opção, codificando-a em `setup.cfg`, o arquivo de configuração para esta distribuição:

    [build_ext]
    inplace=1

Isso afetará todas as construções desta distribuição de módulo, quer você especifique explicitamente ou não build_ext. Se você incluir um `setup.cfg` em sua distribuição fonte, isso também afetará as construções do usuário final – o que provavelmente é uma má ideia para esta opção, já que sempre construir extensões localmente interromperia a instalação da distribuição de módulo. Em certos casos peculiares, porém, os módulos são construídos diretamente em seu diretório de instalação, portanto, esta é uma capacidade útil. (Distribuir extensões que esperam ser construídas em seu diretório de instalação é quase sempre uma má ideia, no entanto.)

Outro exemplo: certos comandos aceitam muitas opções que não mudam de execução para execução; por exemplo, bdist_rpm precisa saber tudo o que é necessário para gerar um arquivo “spec” para criar uma distribuição RPM. Algumas dessas informações vêm do script de configuração e outras são geradas automaticamente pelo Distutils (como a lista de arquivos instalados). Mas algumas delas devem ser fornecidas como opções para bdist_rpm, o que seria muito tedioso de fazer na linha de comando para cada execução. Portanto, aqui está um trecho de código do `setup.cfg` do próprio Distutils:

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

Note que a opção `doc_files` é simplesmente uma string separada por espaços em branco dividida em várias linhas para facilitar a leitura.

Ver também

Sintaxe dos arquivos de configuração em “Instalando Módulos Python”

  Mais informações sobre os arquivos de configuração estão disponíveis no manual para administradores de sistema.

Notas de rodapé

[1]

Este ideal provavelmente não será alcançado até que a configuração automática seja totalmente suportada pelo Distutils.