Ho provato a leggere le domande sulle importazioni dei fratelli e persino sul documentazione pacchetto , ma non ho ancora trovato una risposta.

Con la seguente struttura:

├── LICENSE.md
├── README.md
├── api
│   ├── __init__.py
│   ├── api.py
│   └── api_key.py
├── examples
│   ├── __init__.py
│   ├── example_one.py
│   └── example_two.py
└── tests
│   ├── __init__.py
│   └── test_one.py

Come possono importare gli script nelle directory examplese testsdal file api modulo ed essere eseguiti dalla riga di comando?

Inoltre, vorrei evitare il brutto sys.path.inserthack per ogni file. Sicuramente questo può essere fatto in Python, giusto?

Sette anni dopo

Da quando ho scritto la risposta di seguito, la modifica sys.pathè ancora un trucco semplice e veloce che funziona bene per gli script privati, ma ci sono stati diversi miglioramenti

• L'installazione del pacchetto (in virtualenv o no) ti darà quello che vuoi, anche se suggerirei di usare pip per farlo piuttosto che usare direttamente setuptools (e usaresetup.cfg per archiviare i metadati)
• Usando la -mbandiera e l'esecuzione come pacchetto funzionano (ma risulteranno un po 'scomodi se si desidera convertire la directory di lavoro in un pacchetto installabile).
• Per i test, in particolare, pytest è in grado di trovare il pacchetto api in questa situazione e si occupa degli sys.pathhack per te

Quindi dipende davvero da cosa vuoi fare. Nel tuo caso, però, poiché sembra che il tuo obiettivo sia quello di creare un pacchetto adeguato ad un certo punto, installandolopip -e è probabilmente la soluzione migliore, anche se non è ancora perfetta.

Vecchia risposta

Come già detto altrove, la terribile verità è che devi fare brutti hack per consentire l'importazione da moduli di fratelli o pacchetto genitori da un __main__modulo. Il problema è dettagliato in PEP 366 . PEP 3122 ha tentato di gestire le importazioni in un modo più razionale, ma Guido l'ha respinto per un conto

L'unico caso d'uso sembra essere l'esecuzione di script che si trovano all'interno della directory di un modulo, che ho sempre visto come un antipattern.

( qui )

Tuttavia, uso questo modello regolarmente

# Ugly hack to allow absolute import from the root folder
# whatever its name is. Please forgive the heresy.
if __name__ == "__main__" and __package__ is None:
    from sys import path
    from os.path import dirname as dir

    path.append(dir(path[0]))
    __package__ = "examples"

import api

Ecco path[0]la cartella principale del tuo script in esecuzione edir(path[0]) la cartella di livello superiore.

Tuttavia, non sono stato ancora in grado di utilizzare le importazioni relative con questo, ma consente importazioni assolute dal livello superiore (nella apicartella principale del tuo esempio ).

Stanco degli hack di sys.path?

Ce ne sono molti sys.path.append -hack disponibili, ma ho trovato un modo alternativo per risolvere il problema in mano.

Sommario

• Avvolgere il codice in una cartella (ad es. packaged_stuff)
• Usa lo setup.pyscript di creazione in cui usi setuptools.setup () .
• Pip installa il pacchetto in stato modificabile con pip install -e <myproject_folder>
• Importa utilizzando from packaged_stuff.modulename import function_name

Impostare

Il punto di partenza è la struttura del file che hai fornito, racchiusa in una cartella chiamata myproject.

.
└── myproject
    ├── api
    │   ├── api_key.py
    │   ├── api.py
    │   └── __init__.py
    ├── examples
    │   ├── example_one.py
    │   ├── example_two.py
    │   └── __init__.py
    ├── LICENCE.md
    ├── README.md
    └── tests
        ├── __init__.py
        └── test_one.py

Chiamerò la .cartella principale e nel mio caso di esempio si trova in C:\tmp\test_imports\.

api.py

Come test case, usiamo il seguente ./api/api.py

def function_from_api():
    return 'I am the return value from api.api!'

test_one.py

from api.api import function_from_api

def test_function():
    print(function_from_api())

if __name__ == '__main__':
    test_function()

Prova a eseguire test_one:

PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
Traceback (most recent call last):
  File ".\myproject\tests\test_one.py", line 1, in <module>
    from api.api import function_from_api
ModuleNotFoundError: No module named 'api'

Anche provare le importazioni relative non funzionerà:

L'uso from ..api.api import function_from_apisarebbe risultato in

PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
Traceback (most recent call last):
  File ".\tests\test_one.py", line 1, in <module>
    from ..api.api import function_from_api
ValueError: attempted relative import beyond top-level package

passi

1. Crea un file setup.py nella directory di livello principale

I contenuti per il setup.pysarebbero *

from setuptools import setup, find_packages

setup(name='myproject', version='1.0', packages=find_packages())

2. Usa un ambiente virtuale

Se hai familiarità con gli ambienti virtuali, attivane uno e vai al passaggio successivo. L'uso di ambienti virtuali non è assolutamente necessario, ma ti aiuteranno davvero a lungo termine (quando hai in corso più di 1 progetto ...). I passaggi più basilari sono (esegui nella cartella principale)

• Crea un ambiente virtuale
  • python -m venv venv
• Attiva env virtuale
  • source ./venv/bin/activate(Linux, macOS) o ./venv/Scripts/activate(Win)

Per saperne di più su questo, basta uscire da Google "tutorial virtuale su Python" o simili. Probabilmente non avrai mai bisogno di altri comandi oltre a creare, attivare e disattivare.

Dopo aver creato e attivato un ambiente virtuale, la console dovrebbe fornire il nome dell'ambiente virtuale tra parentesi

PS C:\tmp\test_imports> python -m venv venv
PS C:\tmp\test_imports> .\venv\Scripts\activate
(venv) PS C:\tmp\test_imports>

e l'albero delle cartelle dovrebbe apparire così **

.
├── myproject
│   ├── api
│   │   ├── api_key.py
│   │   ├── api.py
│   │   └── __init__.py
│   ├── examples
│   │   ├── example_one.py
│   │   ├── example_two.py
│   │   └── __init__.py
│   ├── LICENCE.md
│   ├── README.md
│   └── tests
│       ├── __init__.py
│       └── test_one.py
├── setup.py
└── venv
    ├── Include
    ├── Lib
    ├── pyvenv.cfg
    └── Scripts [87 entries exceeds filelimit, not opening dir]

3. pip installa il tuo progetto in stato modificabile

Installa il tuo pacchetto di livello superiore myprojectutilizzando pip. Il trucco è usare la -ebandiera durante l'installazione. In questo modo viene installato in uno stato modificabile e tutte le modifiche apportate ai file .py verranno automaticamente incluse nel pacchetto installato.

Nella directory principale, eseguire

pip install -e . (notare il punto, sta per "directory corrente")

Puoi anche vedere che è installato usando pip freeze

(venv) PS C:\tmp\test_imports> pip install -e .
Obtaining file:///C:/tmp/test_imports
Installing collected packages: myproject
  Running setup.py develop for myproject
Successfully installed myproject
(venv) PS C:\tmp\test_imports> pip freeze
myproject==1.0

4. Aggiungi myproject.alle tue importazioni

Tieni presente che dovrai aggiungere myproject.solo le importazioni che altrimenti non funzionerebbero. Le importazioni che hanno funzionato senza setup.pye pip installfunzioneranno ancora bene. Vedi un esempio di seguito.

Prova la soluzione

Ora, testiamo la soluzione usando api.pydefinito sopra e test_one.pydefinito di seguito.

test_one.py

from myproject.api.api import function_from_api

def test_function():
    print(function_from_api())

if __name__ == '__main__':
    test_function()

eseguendo il test

(venv) PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
I am the return value from api.api!

* Vedi i documenti setuptools per esempi più dettagliati di setup.py.

** In realtà, potresti mettere il tuo ambiente virtuale ovunque sul tuo disco rigido.

Ecco un'altra alternativa che inserisco nella parte superiore dei file Python nella testscartella:

# Path hack.
import sys, os
sys.path.insert(0, os.path.abspath('..'))

Non hai bisogno e non dovresti hackerare a sys.pathmeno che non sia necessario e in questo caso non lo è. Uso:

import api.api_key # in tests, examples

Esegui dalla directory del progetto: python -m tests.test_one .

Probabilmente dovresti spostarti tests(se sono unittest di api) all'interno apied eseguire python -m api.testper eseguire tutti i test (supponendo che ci sia __main__.py) o python -m api.test.test_oneper eseguiretest_one invece.

Potresti anche rimuovere __init__.pyda examples(non è un pacchetto Python) ed eseguire gli esempi in un virtualenv in cui apiè installato, ad esempio, pip install -e .in un virtualenv installerebbe un apipacchetto inplace se hai ragione setup.py.

Non ho ancora la comprensione di Pythonology necessaria per vedere il modo previsto di condividere il codice tra progetti non correlati senza un hack di importazione fratello / fratello. Fino a quel giorno, questa è la mia soluzione. Per exampleso testsper importare cose da ..\api, sarebbe simile a:

import sys.path
import os.path
# Import from sibling directory ..\api
sys.path.append(os.path.dirname(os.path.abspath(__file__)) + "/..")
import api.api
import api.api_key

Per le importazioni di pacchetti fratelli, è possibile utilizzare il metodo insert o append del modulo [sys.path] [2] :

if __name__ == '__main__' and if __package__ is None:
    import sys
    from os import path
    sys.path.append( path.dirname( path.dirname( path.abspath(__file__) ) ) )
    import api

Questo funzionerà se avvii i tuoi script come segue:

python examples/example_one.py
python tests/test_one.py

D'altra parte, puoi anche usare l'importazione relativa:

if __name__ == '__main__' and if __package__ is not None:
    import ..api.api

In questo caso dovrai avviare il tuo script con l' argomento '-m' (nota che, in questo caso, non devi dare l' estensione '.py' ):

python -m packageName.examples.example_one
python -m packageName.tests.test_one

Naturalmente, puoi mescolare i due approcci, in modo che il tuo script funzioni indipendentemente da come viene chiamato:

if __name__ == '__main__':
    if __package__ is None:
        import sys
        from os import path
        sys.path.append( path.dirname( path.dirname( path.abspath(__file__) ) ) )
        import api
    else:
        import ..api.api

TLDR

Questo metodo non richiede setuptools, path hack, argomenti aggiuntivi da riga di comando o specificare il livello superiore del pacchetto in ogni singolo file del progetto.

Basta creare uno script nella directory principale di qualunque cosa tu stia chiamando per essere tuo __main__ed eseguire tutto da lì. Per ulteriori spiegazioni continua a leggere.

Spiegazione

Ciò può essere realizzato senza hackerare insieme un nuovo percorso, argomenti aggiuntivi da riga di comando o aggiungere codice a ciascuno dei tuoi programmi per riconoscere i suoi fratelli.

La ragione per cui questo fallisce come credo sia stato menzionato prima è che i programmi chiamati hanno il loro __name__set come__main__ . Quando ciò si verifica, lo script chiamato accetta se stesso di essere al livello superiore del pacchetto e rifiuta di riconoscere gli script nelle directory dei fratelli.

Tuttavia, tutto sotto il livello superiore della directory riconoscerà ANYTHING ELSE sotto il livello superiore. Ciò significa che l' unica cosa che devi fare per ottenere i file nelle directory dei fratelli per riconoscersi / utilizzarli è chiamarli da uno script nella loro directory principale.

Proof of Concept In un dir con la seguente struttura:

.
|__Main.py
|
|__Siblings
   |
   |___sib1
   |   |
   |   |__call.py
   |
   |___sib2
       |
       |__callsib.py

Main.py contiene il seguente codice:

import sib1.call as call


def main():
    call.Call()


if __name__ == '__main__':
    main()

sib1 / call.py contiene:

import sib2.callsib as callsib


def Call():
    callsib.CallSib()


if __name__ == '__main__':
    Call()

e sib2 / Callsib.py contiene:

def CallSib():
    print("Got Called")

if __name__ == '__main__':
    CallSib()

Se riproduci questo esempio, noterai che la chiamata Main.pycomporterà la stampa di "Chiamato" come definito, sib2/callsib.py anche se sib2/callsib.pyviene richiamato sib1/call.py. Tuttavia, se si dovesse chiamare direttamente sib1/call.py(dopo aver apportato le opportune modifiche alle importazioni) si genera un'eccezione. Anche se ha funzionato quando chiamato dallo script nella sua directory principale, non funzionerà se si ritiene che si trovi al livello più alto del pacchetto.

Ho realizzato un progetto di esempio per dimostrare come ho gestito questo, che in effetti è un altro hack sys.path come indicato sopra. Esempio di importazione di Python Sibling , che si basa su:

if __name__ == '__main__': import os import sys sys.path.append(os.getcwd())

Questo sembra essere abbastanza efficace fintanto che la directory di lavoro rimane alla radice del progetto Python. Se qualcuno lo distribuisce in un vero ambiente di produzione, sarebbe bello sapere se funziona anche lì.

Devi guardare per vedere come sono scritte le dichiarazioni di importazione nel relativo codice. Se examples/example_one.pyutilizza la seguente dichiarazione di importazione:

import api.api

... quindi si aspetta che la directory principale del progetto si trovi nel percorso di sistema.

Il modo più semplice per supportare questo senza alcun hack (come lo hai messo) sarebbe quello di eseguire gli esempi dalla directory di livello superiore, in questo modo:

PYTHONPATH=$PYTHONPATH:. python examples/example_one.py 

Nel caso in cui qualcuno che utilizza Pydev su Eclipse finisca qui: è possibile aggiungere il percorso padre del fratello (e quindi il padre del modulo chiamante) come cartella di libreria esterna usando Progetto-> Proprietà e impostando Librerie esterne nel menu a sinistra Pydev-PYTHONPATH . Quindi puoi importare dal tuo fratello, ad esfrom sibling import some_class .

Innanzitutto, dovresti evitare di avere file con lo stesso nome del modulo stesso. Potrebbe interrompere altre importazioni.

Quando si importa un file, prima l'interprete controlla la directory corrente e quindi cerca le directory globali.

All'interno exampleso testspuoi chiamare:

from ..api import api