PYTHONPATH vs. sys.path

Question

Un altro sviluppatore e non sono d'accordo sul fatto che PYTHONPATH o sys.path dovrebbe essere utilizzata per consentire Python per trovare un pacchetto Python in un utente (ad esempio, lo sviluppo) directory.

Abbiamo un progetto Python con una tipica struttura di directory:

Project
    setup.py
    package
        __init__.py
        lib.py
        script.py

In script.py, abbiamo bisogno di fare import package.lib. Quando il pacchetto è installato in site-packages, script.py può trovare package.lib.

Quando si lavora da una directory utente, però, qualcosa deve essere fatto. La mia soluzione è quella di impostare il mio PYTHONPATH per includere "~ / Progetto". Un altro sviluppatore vuole mettere questa riga di codice all'inizio del script.py:

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

In modo che Python riesce a trovare la copia locale del package.lib.

Penso che questa sia una cattiva idea, in quanto questa linea è utile solo per gli sviluppatori o persone in esecuzione di una copia locale, ma non riesco a dare un buon motivo per cui è una cattiva idea.

dovremmo usare PYTOHNPATH, sys.path, o è o multa?

Answer 1

Se l'unica ragione per modificare il percorso è per gli sviluppatori che lavorano dal loro albero di lavoro, quindi si dovrebbe utilizzare uno strumento di installazione per configurare l'ambiente per voi. virtualenv è molto popolare, e se si utilizza setuptools, si può semplicemente eseguire setup.py develop a semi-installare l'albero di lavoro nella vostra installazione di Python corrente.

Answer 2

Odio PYTHONPATH. Trovo fragili e fastidioso per impostare su una base per-user (in particolare per gli utenti daemon) e tenere traccia di come cartelle di progetto muoversi. Avrei preferito impostare sys.path negli script invoke per i progetti indipendenti.

Tuttavia sys.path.append non è il modo per farlo. Si può facilmente ottenere i duplicati, e non risolvere i file .pth. Meglio (e più leggibile):. site.addsitedir

E script.py non sarebbe normalmente il luogo più appropriato per farlo, come è all'interno il pacchetto che si desidera rendere disponibili sul sentiero. moduli di libreria non devono certamente essere tocchino sys.path stessi. Invece, che normalmente si dispone di un hashbanged-script di fuori del pacchetto che si utilizza per creare un'istanza ed eseguire l'applicazione, ed è in questo script wrapper banale che ci si mette dettagli di distribuzione come sys.path-incasinando.

Answer 3

In generale vorrei prendere in considerazione la creazione di una variabile d'ambiente (come PYTHONPATH) di essere una cattiva pratica. Anche se questo potrebbe andare bene per un una tantum di debug, ma usando questo come
una pratica regolare potrebbe non essere una buona idea.

L'utilizzo di variabile d'ambiente porta a situazioni come "funziona per me" quando qualcuno
altro riporta problemi nel codice di base. Inoltre si potrebbe portare la stessa pratica con la ambiente di prova così, portando a situazioni come i test in esecuzione bene per un sviluppatore particolare ma probabilmente non riuscendo quando qualcuno lancia i test.

Answer 4

Insieme con i molti altri motivi già citati, si potrebbe anche puntare outh che hard-codifica

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

è fragile perché presume la posizione di script.py - funzionerà solo se script.py si trova in Project / package. Si romperà se un utente decide di spostare / copiare / script.py link simbolico (quasi) qualsiasi altro luogo.

Answer 5

Credo, che in questo caso utilizzando PYTHONPATH è una cosa migliore, soprattutto perché non introduce (discutibile) del codice inutile.

Dopo tutto, se si pensa di esso, il tuo utente non ha bisogno che cosa sys.path, perché il pacchetto otterrà installato in site-packages, perché si prevede di utilizzare un sistema di confezionamento.

Se l'utente sceglie di eseguire da un "copia locale", come lo chiami tu, poi io ho osservato, che la pratica usuale è quello di stato, che il pacchetto deve essere aggiunto a PYTHONPATH manualmente, se utilizzato al di fuori del site-packages.