Import eines Skripts aus einem anderen Paket mit Skripten

[[An...]]

Hallo allerseits...

Die Beispiel-Struktur der Skripte im Skripteditor zeigt das angefügte Bild. In einem ersten Paket "Skriptpaket1" sind drei Skripte enthalten, in einem zweiten Paket "Skriptpaket2" sind weitere drei Skripte enthalten.

Ich möchte nun in die Skripte des "Skriptpaket1" Skripte aus dem "Skriptpaket2" importieren mit dem Python-Befehl "import".

 

Frage:

Wie muss die Syntax für den Import richtigerweise lauten?

 

Konstruktionen à la

from Skriptpaket2 import Skript4

oder

from .Skriptpaket2 import Skript4

usw. haben leider nicht zum Ziel geführt.

 

Danke im voraus für jede Hilfe!

[[Je...]]

Hallo Andreas,

ohne es getestet zu haben, versuche mal bitte dies hier:

    from .Skriptpaket2.Skriptpaket2.modules import Skript4

Wenn du die gesamte Struktur/Hirarchie abbildest, sollte es funktionieren.

Gruß, Jens

[[An...]]

Hallo Jens,

Danke für den Tip, aber das funktioniert so leider nicht. Skripte, die in Paketen sind, scheinen nicht in der üblichen Python-Skripthierarchie zu liegen.

[[Je...]]

Ich war unachtsam!
Bei "Skriptpaket1" und "Skriptpaket2" handelt es sich um zwei unabhängige Umgebungen.
Skript-Umgebungen sind gegeneinander abgeschottet, damit man in ihnen z.B. unterschiedliche Versionen des gleichen Pakets nutzen kann.

Zwischen den Umgebungen kann also nicht kommuniziert werden, da vorsätzlich keine Verbindung besteht.

[[Fr...]]

Das stimmt. Beim Umstieg auf korrekte Skriptumgebungen mussten diese vollständig getrennt werden, da es ansonsten ein Gemisch auf Abhängigkeiten geben kann. Wenn beispielsweise Umgebung #1 numpy-1.37.2 mitliefert aber Umgebung #2 numpy-1.23.7 mitbringt, wäre das ein unlösbarer Konflikt.

Daher sind wir auf die Standard-Python-Methode zurückgefallen: Soll beispielsweise eine Skriptsammlung in mehreren Paketen wie eine Basis-Bibliothek benutzt werden können, kann man diese als "Python-Wheel" zusammenstellen und dieses Wheel dann wie alle anderen Wheels der Umgebung mit den Paketen zusammen ausliefern. Das hat auch die Vorteile, dass so ein Paket komplett "self-contained" ist, also ohne weitere externe Abhängigkeiten herum gereicht werden kann, und dass man in verschiedenen Paketen verschiedene Versionen dieser Basisbibliothek unterbringen kann.

Für das Bauen eines Wheels gibt es im Netz diverse Tutorien, wir sind leider noch nicht dazu gekommen, dies für den speziellen Fall Pakete explizit zu dokumentieren. Wir werden dazu aber noch eine genaue Beschreibung unter https://zeissiqs.github.io/gom-software-python-api/2022/ veröffentlichen.

[[An...]]

Hallo Herr Blankenburg,

vielen Dank für Ihre Antwort! Das, was Sie da schildern, trifft meinen Anwendungsfall recht gut: ich habe drei Skripte, welche bestimmte "Standardfunktionen" enthalten. Diese drei Skripte will ich in ein Paket packen, so dass ich dieses "Framework" relativ gut verteilen kann. Von anderen Skripten aus (die sich in "Benutzerdefinierte Skripte" befinden können oder aber auch in anderen Paketen) möchte ich dann aber natürlich auf dieses "Framework" zugreifen können!

Es wäre schön, wenn Ihre Beschreibung zur Erzeugung eines "Wheel" nicht allzu lange auf sich warten lässt! 😉

[[An...]]

Wie ist der Stand zur Veröffentlichung der Dokumentation des Aufbaus und der Nutzung eines Wheels zusammen mit Paketen in GOM Inspect?

Unter dem von Ihnen genannten Link kann ich bisher nichts dazu finden.

Danke im voraus für die Information!

[[An...]]

Falls jemand von ZEISS/GOM hier mitliest:

Bitte informieren Sie mich darüber, ob das von mir hier angesprochene Thema im Forum noch beantwortet wird oder ob ich mich damit an den Support wenden soll.

Danke!

[[An...]]

Wie ist der Stand bezüglich dieser "Wheels" und einer entsprechenden Beschreibung?

Danke im voraus für die Informationen!

[[Ma...]]

Hallo Herr Gallasch,

unter https://zeissiqs.github.io/zeiss-inspect-addon-api/2023/howtos/using_shared_environments/using_shared_environments.html finden Sie eine entsprechende Anleitung mit Beispielen. Ich hoffe dies hilft Ihnen weiter.

Viele Grüße

Matthias Prinke

 

[[Fr...]]

Mich hat gerade ein Kollege darauf hingewiesen, dass diese Frage hier komplett untergangen ist. Das tut mir leid, da ging der Watch verloren.

In diesem Thread habe ich noch etwas mehr zum Thema "Mischen von Environments" geschrieben:

• In der SW2023 können wir mehrere Add-Ons in einen gemeinsamen Namespace kombinieren. In dem weiter oben geposteten Link ist das genauer beschrieben.
• Eigene "Wheels" bauen für grundlegende Python-Funktionalitäten kann man zusätzlich dazu. Das ist noch nicht dokumentiert, aber entspricht dem Standard-Vorgehen in Python: [Link] Davon würde ich aber eher abraten, es sein denn, man baut seine Add-Ons nicht interaktiv in ZEISS Inspect sondern beispielsweise in einem eigenen Build-System per Skripte. Einige 3rd-Party-Entwickler machen das so.

 

[[An...]]

Hallo Herr Blankenburg,

gibt es mittlerweile die von Ihnen im Beitrag vom 15.09.2023 genannte Dokumentation?

Danke im voraus für eine Information dazu.