Jump to content

Import eines Skripts aus einem anderen Paket mit Skripten


---
 Share

Recommended Posts

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!

Skriptstruktur.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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! 😉

Link to comment
Share on other sites

  • 3 months later...

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!

Link to comment
Share on other sites

  • 1 month later...

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!

Link to comment
Share on other sites

  • 4 months later...

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.

 

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

 Share

×
×
  • Create New...