Normalerweise können per "import" andere Module / Skripte in entsprechenden Verzeichnissen eingebunden werden. Nun gibt es Umgebungen, in denen das nicht möglich ist: Man kann zwar Pakete installieren, aber nicht auf andere Ressourcen verweisen. So beispielsweise beim in-database-Python im SQL Server. Oder wenn ich Azure Data Studio Notebooks zum Ausführen von Skripten verwende.
Was sind die Alternativen zum Import? Wenn Skript B das Skript A importieren soll, muss dann stattdessen der vollständige Code von Skript A im Skript B enthalten sein? Oder gibt es noch andere Möglichkeiten?
Alternativen zum Import von Programm-Modulen?
Wie kommst Du auf diesen Irrglauben?
Ich hab zwar Azure Data Studio noch nie angeschaut, aber die Dokumentation kann ich lesen:
https://docs.microsoft.com/de-de/sql/bi ... e-packages
Ich hab zwar Azure Data Studio noch nie angeschaut, aber die Dokumentation kann ich lesen:
https://docs.microsoft.com/de-de/sql/bi ... e-packages
Python klappert eine ganze Reihe von Verzeichnissen ab, um Module aufzufinden und mit der Umgebungsvariable 'PYTHONPATH' kann man zusätzlich welche setzen. Welche Pfade das sind, kann man zum Beispiel mit 'python -m site' abfragen (das wichtigste steht in sys.path, welches auch aus Python heraus einfach abfragbar ist):
Falls du es schaffst, Module an irgendeinem dieser Ort abzulegen, kannst du sie auch importieren (wobei einige dabei weniger präferriert sind, als andere... aber wenn es nicht anders geht).
Sollte das tatsächlich nicht möglich sein, kann man das von dir vorgeschlagene Einbetten versuchen. Das klappt aber nur in sehr trivialen Fällen "einfach so". Wenn man es mit Paketen, die eine komplexere interne Struktur aufweisen und möglicherweise gar in C geschrieben sind zu tun hat, wird das nach meinem Eindruck nicht klappen.
Allerdings würde ich möglichst noch mal in die Dokumentation der von dir angesprochenen Produkte schauen, ob es da nicht doch Wege gibt.
Code: Alles auswählen
PYTHONPATH='/tmp' python -m site
sys.path = [
'/home/user',
'/tmp',
'/usr/lib/python37.zip',
'/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload',
'/home/user/.local/lib/python3.7/site-packages',
'/usr/lib/python3.7/site-packages',
]
USER_BASE: '/home/user/.local' (exists)
USER_SITE: '/home/user/.local/lib/python3.7/site-packages' (exists)
ENABLE_USER_SITE: True
Sollte das tatsächlich nicht möglich sein, kann man das von dir vorgeschlagene Einbetten versuchen. Das klappt aber nur in sehr trivialen Fällen "einfach so". Wenn man es mit Paketen, die eine komplexere interne Struktur aufweisen und möglicherweise gar in C geschrieben sind zu tun hat, wird das nach meinem Eindruck nicht klappen.
Allerdings würde ich möglichst noch mal in die Dokumentation der von dir angesprochenen Produkte schauen, ob es da nicht doch Wege gibt.
@Sirius3
Bezüglich Azure Data Studio lag ich falsch. Da kann man sich ja den Ort der Installation anschauen und dort vielleicht auch irgendwo andere Skripte an Orten ablegen, die "abgeklappert" werden.
Im SQL Server geht das vielleicht, und ist dabei wohl eher nicht vorgesehen. Da soll man auch kein pip verwenden, sondern einen anderen Weg gehen, um Pakete zu installieren. Das leuchtet auch ein, wenn man davon ausgeht, dass es nur einen geregelten Zugang zur Python-Installation geben soll. Natürlich gibt es auch da im Hintergrund ein Python-Verzeichnis.
https://docs.microsoft.com/de-de/sql/ad ... erver-2017
Vielleicht muss man auch überlegen, was man direkt im SQL Server machen will, und was besser außerhalb. Der Sinn der eingebauten Python-Funktionalität ist es sicherlich vor allem, Daten an Python zu übergeben, mit Python zu bearbeiten, das Ergebnis zurück in den SQL Server zu schreiben. Somit kann man das dann auch von innerhalb des SQL Servers steuern.
Bezüglich Azure Data Studio lag ich falsch. Da kann man sich ja den Ort der Installation anschauen und dort vielleicht auch irgendwo andere Skripte an Orten ablegen, die "abgeklappert" werden.
Im SQL Server geht das vielleicht, und ist dabei wohl eher nicht vorgesehen. Da soll man auch kein pip verwenden, sondern einen anderen Weg gehen, um Pakete zu installieren. Das leuchtet auch ein, wenn man davon ausgeht, dass es nur einen geregelten Zugang zur Python-Installation geben soll. Natürlich gibt es auch da im Hintergrund ein Python-Verzeichnis.
https://docs.microsoft.com/de-de/sql/ad ... erver-2017
Vielleicht muss man auch überlegen, was man direkt im SQL Server machen will, und was besser außerhalb. Der Sinn der eingebauten Python-Funktionalität ist es sicherlich vor allem, Daten an Python zu übergeben, mit Python zu bearbeiten, das Ergebnis zurück in den SQL Server zu schreiben. Somit kann man das dann auch von innerhalb des SQL Servers steuern.