setuptools: percorso della cartella dei dati del pacchetto

Uso setuptools per distribuire il mio pacchetto python. Ora ho bisogno di distribuire file di dati aggiuntivi.

Da quello che ho raccolto dalla documentazione di setuptools, ho bisogno di avere i miei file di dati all'interno della directory del pacchetto. Tuttavia, preferirei avere i miei file di dati all'interno di una sottodirectory nella directory principale.

Cosa vorrei evitare:

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

Quello che vorrei avere invece:

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

Semplicemente non mi sento a mio agio con così tante sottodirectory, se non è essenziale. Non riesco a trovare una ragione per cui devo / devo / mettere i file nella directory del pacchetto. È anche scomodo lavorare con così tante sottodirectory nidificate IMHO. O c'è qualche buona ragione che giustifichi questa restrizione?

Opzione 1: installa come dati del pacchetto

Il vantaggio principale di posizionare i file di dati all'interno della radice del tuo pacchetto Python è che ti consente di evitare di preoccuparti di dove vivranno i file sul sistema di un utente, che può essere Windows, Mac, Linux, qualche piattaforma mobile o all'interno di un Egg. Puoi sempre trovare la directory datarelativa alla radice del tuo pacchetto Python, indipendentemente da dove o come sia installato.

Ad esempio, se ho un layout di progetto in questo modo:

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

È possibile aggiungere una funzione a __init__.pyper individuare un percorso assoluto a un file di dati:

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

Uscite:

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

Dopo che il progetto è stato installato come Egg, il percorso datacambierà, ma non è necessario modificare il codice:

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

Opzione 2: installazione in una posizione fissa

L'alternativa sarebbe inserire i dati fuori dal pacchetto Python e poi:

1. Avere il percorso di datapassato tramite un file di configurazione, argomenti della riga di comando o
2. Incorpora la posizione nel tuo codice Python.

Questo è molto meno desiderabile se prevedi di distribuire il tuo progetto. Se vuoi davvero farlo, puoi installarlo datadove preferisci sul sistema di destinazione specificando la destinazione per ogni gruppo di file passando un elenco di tuple:

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

Aggiornato : esempio di una funzione di shell per eseguire il grep ricorsivo di file Python:

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

Penso di aver trovato un buon compromesso che ti permetterà di mantenere la seguente struttura:

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

Dovresti installare i dati come package_data, per evitare i problemi descritti nella risposta samplebias, ma per mantenere la struttura del file dovresti aggiungere al tuo setup.py:

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

In questo modo creiamo la struttura appropriata "just in time" e manteniamo organizzato il nostro albero dei sorgenti.

Per accedere a tali file di dati all'interno del codice, si utilizza "semplicemente":

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

Non mi piace ancora dover specificare "mypackage" nel codice, poiché i dati potrebbero non avere nulla a che fare necessariamente con questo modulo, ma immagino sia un buon compromesso.

Penso che puoi fondamentalmente dare qualsiasi cosa come argomento * data_files * a setup () .