setuptools: ubicación de la carpeta de datos del paquete

Utilizo setuptools para distribuir mi paquete de Python. Ahora necesito distribuir archivos de datos adicionales.

Por lo que he recopilado de la documentación de setuptools, necesito tener mis archivos de datos dentro del directorio del paquete. Sin embargo, preferiría tener mis archivos de datos dentro de un subdirectorio en el directorio raíz.

Lo que me gustaría evitar:

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

Lo que me gustaría tener en su lugar:

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

Simplemente no me siento cómodo con tener tantos subdirectorios, si no es esencial. No encuentro una razón por la que tengo que poner los archivos dentro del directorio del paquete. También es engorroso trabajar con tantos subdirectorios anidados en mi humilde opinión. ¿O hay alguna buena razón que justifique esta restricción?

Opción 1: instalar como datos de paquete

La principal ventaja de colocar archivos de datos dentro de la raíz de su paquete Python es que le permite evitar preocuparse por dónde vivirán los archivos en el sistema de un usuario, que puede ser Windows, Mac, Linux, alguna plataforma móvil o dentro de un huevo. Siempre puede encontrar el directorio datarelativo a la raíz de su paquete Python, sin importar dónde o cómo esté instalado.

Por ejemplo, si tengo un diseño de proyecto como este:

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

Puede agregar una función para __init__.pylocalizar una ruta absoluta a un archivo de datos:

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')

Salidas:

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

Una vez que el proyecto se instala como Egg, la ruta datacambiará, pero no es necesario que cambie el código:

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

Opción 2: instalar en una ubicación fija

La alternativa sería colocar sus datos fuera del paquete de Python y luego:

1. Tener la ubicación datapasada a través de un archivo de configuración, argumentos de línea de comando o
2. Incruste la ubicación en su código Python.

Esto es mucho menos deseable si planea distribuir su proyecto. Si realmente desea hacer esto, puede instalar su datadonde quiera en el sistema de destino especificando el destino para cada grupo de archivos pasando una lista de tuplas:

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

Actualizado : ejemplo de una función de shell para grep recursivamente archivos Python:

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

Creo que encontré un buen compromiso que te permitirá mantener la siguiente estructura:

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

Debe instalar los datos como package_data, para evitar los problemas descritos en la respuesta de samplebias, pero para mantener la estructura del archivo, debe agregar a su setup.py:

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

De esta manera creamos la estructura apropiada "justo a tiempo" y mantenemos nuestro árbol de fuentes organizado.

Para acceder a dichos archivos de datos dentro de su código, "simplemente" usa:

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

Todavía no me gusta tener que especificar 'mypackage' en el código, ya que los datos podrían no tener nada que ver con este módulo, pero supongo que es un buen compromiso.

Creo que básicamente puedes dar cualquier cosa como argumento * data_files * a setup () .