setuptools: localização da pasta de dados do pacote

Eu uso setuptools para distribuir meu pacote python. Agora preciso distribuir arquivos de dados adicionais.

Pelo que reuni da documentação do setuptools, preciso ter meus arquivos de dados dentro do diretório do pacote. No entanto, prefiro ter meus arquivos de dados dentro de um subdiretório no diretório raiz.

O que eu gostaria de evitar:

/ #root
|- src/
|  |- mypackage/
|  |  |- data/
|  |  |  |- resource1
|  |  |  |- [...]
|  |  |- __init__.py
|  |  |- [...]
|- setup.py

O que eu gostaria de ter em vez disso:

/ #root
|- data/
|  |- resource1
|  |- [...]
|- src/
|  |- mypackage/
|  |  |- __init__.py
|  |  |- [...]
|- setup.py

Eu simplesmente não me sinto confortável em ter tantos subdiretórios, se não for essencial. Não consigo encontrar um motivo pelo qual eu / tenho / para colocar os arquivos dentro do diretório do pacote. Também é complicado trabalhar com tantos subdiretórios IMHO aninhados. Ou há algum bom motivo que justifique essa restrição?

Opção 1: instalar como dados do pacote

A principal vantagem de colocar arquivos de dados dentro da raiz de seu pacote Python é que isso permite que você evite se preocupar com onde os arquivos ficarão no sistema de um usuário, que pode ser Windows, Mac, Linux, alguma plataforma móvel ou dentro de um Egg. Você sempre pode encontrar o diretório datarelativo à raiz do seu pacote Python, não importa onde ou como ele está instalado.

Por exemplo, se eu tiver um layout de projeto como este:

project/
    foo/
        __init__.py
        data/
            resource1/
                foo.txt

Você pode adicionar uma função para __init__.pylocalizar um caminho absoluto para um arquivo de dados:

import os

_ROOT = os.path.abspath(os.path.dirname(__file__))
def get_data(path):
    return os.path.join(_ROOT, 'data', path)

print get_data('resource1/foo.txt')

Saídas:

/Users/pat/project/foo/data/resource1/foo.txt

Depois que o projeto for instalado como um Egg, o caminho para dataserá alterado, mas o código não precisa ser alterado:

/Users/pat/virtenv/foo/lib/python2.6/site-packages/foo-0.0.0-py2.6.egg/foo/data/resource1/foo.txt

Opção 2: instalar em local fixo

A alternativa seria colocar seus dados fora do pacote Python e então:

1. Ter a localização datatransmitida por meio de um arquivo de configuração, argumentos de linha de comando ou
2. Incorpore o local em seu código Python.

Isso é muito menos desejável se você planeja distribuir seu projeto. Se você realmente quiser fazer isso, você pode instalar dataonde quiser no sistema de destino, especificando o destino para cada grupo de arquivos, passando uma lista de tuplas:

from setuptools import setup
setup(
    ...
    data_files=[
        ('/var/data1', ['data/foo.txt']),
        ('/var/data2', ['data/bar.txt'])
        ]
    )

Atualizado : exemplo de uma função shell para executar grep recursivamente em arquivos Python:

atlas% function grep_py { find . -name '*.py' -exec grep -Hn $* {} \; }
atlas% grep_py ": \["
./setup.py:9:    package_data={'foo': ['data/resource1/foo.txt']}

Acho que encontrei um bom compromisso que lhe permitirá manter a seguinte estrutura:

/ #root
|- data/
|  |- resource1
|  |- [...]
|- src/
|  |- mypackage/
|  |  |- __init__.py
|  |  |- [...]
|- setup.py

Você deve instalar os dados como package_data, para evitar os problemas descritos na resposta samplebias, mas para manter a estrutura do arquivo você deve adicionar ao seu setup.py:

try:
    os.symlink('../../data', 'src/mypackage/data')
    setup(
        ...
        package_data = {'mypackage': ['data/*']}
        ...
    )
finally:
    os.unlink('src/mypackage/data')

Desta forma criamos a estrutura apropriada "just in time", e mantemos nossa árvore de origem organizada.

Para acessar esses arquivos de dados dentro do seu código, você "simplesmente" usa:

data = resource_filename(Requirement.parse("main_package"), 'mypackage/data')

Ainda não gosto de ter que especificar 'mypackage' no código, pois os dados não podem ter nada a ver necessariamente com este módulo, mas acho que é um bom compromisso.

Eu acho que você pode basicamente fornecer qualquer coisa como argumento * data_files * para setup () .