Das deutsche Python-Forum

Hallo zusammen,

ich habe einiges zu dem Thema gelesen und alles, was ich gelesen habe, auch ausprobiert; aber dennoch verzweifle ich gerade.
Ich möchte keine Umgehungslösungen sondern gehe davon aus, dass es irgendwie 'richtig' gehen muss.

Dieses Thema wird häufig gefragt und bei vielen auch gelöst - aber dennoch funktioniert das, was bei anderen funktioniert, bei mir nicht.
Obwohl: wahrscheinlicher ist es, dass ich irgendetwas falsch mache - ich sehe aber nicht, was.

Ich befinde mich in einer WSL2-Umgebung mit Ubuntu und habe eine Projektstruktur in der sich mehrere 'Programme' (app1, app2 .. appn) befinden sollen, in denen ich mit der Selenium-Library etwas herumspielen möchte; das aber nur am Rande.
Parallel zu den appx-Verzeichnissen befindet sich ein Verzeichnis base, in welchem Python-Skripte liegen sollen, die von allen Apps genutzt werden können (ja, ich werde base noch in common ändern)

Nun möchte ich in app1 ein Skript aus dem Verzeichnis base importieren - und da hapert es.
Wie bereits erwähnt, habe ich vieles ausprobiert

• - relative Pfade
  - absolute Pfade
  - Aufruf des Scriptes aus verschiedenen Arbeitsverzeichnissen
  - ...

All das führt zu Meldungen a la 'module not found' oder 'relative import with no know parent package'
Ich werde nicht alle gemachten Versuche hier dokumentieren, es sei denn, Ihr möchtet das.

Aber das, was meiner Meinung nach funktionieren sollte ist folgendes:

Verzeichnisstruktur:


Aufruf:


Fehler:


Ich hoffe, Ihr könnt mir helfen.

Besten Dank im Voraus!
Sascha

Das Verzeichnis in dem apps/ liegt muß im Suchpfad von Python sein. Z.b. indem du app1 als Modul ausführst:

Du kannst nicht tief in die Pakethierarchie reinlangten und ein Skript ausführen. Die müssen an der Wurzel stehen, oder als entry points aus einem setup.py erzeugt werden.

Hallo Sirius.

Sirius3 hat geschrieben: Mittwoch 28. April 2021, 07:52 Das Verzeichnis in dem apps/ liegt muß im Suchpfad von Python sein. Z.b. indem du app1 als Modul ausführst:

Code: Alles auswählen

python -m apps.app1.app

Das habe ich probiert - leider funktioniert auch das nicht Ich kriege hier echt noch nen Fön


EDIT: man sollte richtig lesen!!! apps.app1.app - nicht apps/app1/app
Danke Sirius; so funktioniert es!


Hallo __deets__.

__deets__ hat geschrieben: Mittwoch 28. April 2021, 07:59 Du kannst nicht tief in die Pakethierarchie reinlangten und ein Skript ausführen. Die müssen an der Wurzel stehen, oder als entry points aus einem setup.py erzeugt werden.

Vielen Dank auch Dir. Da ich ja nicht wirklich ein Package in dem Sinne haben möchte, sondern meine Skripte irgendwie 'fachlich' sortiert -> macht das da Sinn mit setup.py? Oder interpretiere ich das falsch?

Wenn du kein Package willst, dann mach keine, und schmeiss die __init__.py weg. Dann kannst du deine Skripte auch benutzen. Allerdings hast du dann auch kein geteiltes base-Paket mehr. Wenn du das willst, dann musst du eben entweder die Skripte auf die root-Ebene ziehen, weil deren Verzeichnis in sys.path gepackt wird, und erst dadurch "base" importierbar wird, oder du musst das anderweitig erreichen. ZB durch setup.py oder durch explizite Manipulation von sys.path in jedem entry-Skript.

__deets__ hat geschrieben: Mittwoch 28. April 2021, 09:44 Wenn du kein Package willst, dann mach keine, und schmeiss die __init__.py weg. Dann kannst du deine Skripte auch benutzen. Allerdings hast du dann auch kein geteiltes base-Paket mehr. Wenn du das willst, dann musst du eben entweder die Skripte auf die root-Ebene ziehen, weil deren Verzeichnis in sys.path gepackt wird, und erst dadurch "base" importierbar wird, oder du musst das anderweitig erreichen. ZB durch setup.py oder durch explizite Manipulation von sys.path in jedem entry-Skript.

Ja, die __init__.py's habe ich jetzt entsorgt. Ich starte die Scripte jetzt mit -m und so funktioniert alles so, wie ich mir das vorstelle.

@sfx2k: Wenn Du die mit `-m` startest, dann solltest Du die `__init__.py`\s da auch wieder hinpacken, denn sonst sind das „namespace packages“, was sie ja aber nicht sind, und das kann dann irgendwann zu Problemen führen wenn da plötzlich Module auftauchen die woanders im Dateisystem liegen.

__blackjack__ hat geschrieben: Mittwoch 28. April 2021, 13:40 @sfx2k: Wenn Du die mit `-m` startest, dann solltest Du die `__init__.py`\s da auch wieder hinpacken, denn sonst sind das „namespace packages“, was sie ja aber nicht sind, und das kann dann irgendwann zu Problemen führen wenn da plötzlich Module auftauchen die woanders im Dateisystem liegen.

@__blackjack__: alles klar, wird gemacht. Vielen Dank. Ich glaube, ich werde mich heute mal näher in diese Thematik einlesen müssen...