Python OBJECT_DISPATCH error with accompanying irisload.py error

Question

Question

Jonathan Lent · Sep 25, 2023

All,

I've asked my teammate to open a WRC on this issue, but wanted to open the discussion to see if maybe we aren't the first people to see this issue.

The code we are deploying is a COS object with some Python methods. The code works fine locally on the developer's machine. However, when the business process runs in the server environment, we see the following when COS code attempts to call a [Language = python] method:

In component Event Log:
ERROR <Ens>ErrException: <OBJECT DISPATCH>ValidateSheet+9 ^ClientPortal.Process.FinalClientAdjustmentApprovalProcess.1 *python object not found -- logged as '-'
number - @'
Set tReturnMsg = ..GetExcelRowCount(tFileName) '

In the System Message Log:
09/25/23-09:41:32:896 (17880) 0 [Python] spec.__path__ = path + [currentName]
09/25/23-09:41:32:896 (17880) 0 [Python] TypeError
09/25/23-09:41:32:896 (17880) 0 [Python] :
09/25/23-09:41:32:896 (17880) 0 [Python] unsupported operand type(s) for +: '_NamespacePath' and 'list'
09/25/23-09:41:38:352 (13436) 0 [Python] Traceback (most recent call last):
09/25/23-09:41:38:352 (13436) 0 [Python] File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
09/25/23-09:41:38:352 (13436) 0 [Python] File "<frozen importlib._bootstrap>", line 982, in _find_and_load_unlocked
09/25/23-09:41:38:353 (13436) 0 [Python] File "<frozen importlib._bootstrap>", line 925, in _find_spec
09/25/23-09:41:38:353 (13436) 0 [Python] File "g:\intersystems\irishealth2019\lib\python\irisloader.py", line 179, in find_spec

From what I can tell, I gather that the code expects the left and right side of the "+" operator to be made of objects where it makes sense to concatenate them -- and in this case that is not happening.

Anybody seen this before and, even better, know the root cause?

Cordially,

Jonathan

Product version: IRIS 2023.1

$ZV: IRIS for Windows (x86-64) 2023.1 (Build 235_1U) Fri Jun 2 2023 13:30:56 EDT [Health:5.1.0]

Discussion (5)1

Log in or sign up to continue

Jonathan Lent · Sep 29, 2023

UPDATE: Adhering to PEP8 conventions on naming packages using lower-case letters and underscores nicely sidesteps this issue. So, for namespace with a root package of "MyFirstPackage" would have a lib/python/myfirstpackage folder with any .py files that need to accompany the namespace in it.

The loader failing because the package matched the root namespace is probably still a bug of some sort, but now that I know a little better about naming conventions I can see why this might not have been tested.

Hope this saves some of you norms (like me) some time if you run across it.

0 0

score 0 · Answer 1 · 2023-09-26T05:59:58-04:00

Eduard Lebedyuk · Sep 26, 2023

Can you run: do $system.Python.Shell() on a server?

0 0

score 0 · Answer 2 · 2023-09-26T10:07:34-04:00

Yep.

%SYS>Do $system.Python.Shell()

Python 3.9.5 (default, Jun 2 2023, 14:12:21) [MSC v.1927 64 bit (AMD64)] on win32
Type quit() or Ctrl-D to exit this shell.
>>>

score 0 · Answer 3 · 2023-09-26T12:20:45-04:00

As I try to go a little deeper into importlib, it seems that find_spec should be passed a path that "produces strings when iterated" and there is something about the deployment environment that is causing path to be passed as a string in this case. Only happens when using python-augmented (method) COS classes, as far as I can tell.

score 0 · Answer 4 · 2023-09-28T13:08:05-04:00

Okay, here's the latest.

I had started to outfit some of our repos with boilerplate IPM modules to take advantage of the requirements.txt processing. Modeling some of the things mu team and I had seen elsewhere, we put a FileCopy in the module file to copy the contents of the repo's python directory to a subdirectory of lib/python that matched the root package name.

A high-speed team member picked through the custom loader to suss out the behavior and found that once it encountered the subdirectory matching the root package name, the resolution of the modules that are stored in globals never happened.

So, removing the directory restored the default loading behavior and I will caulk it up to my poor understanding of how repo-based modules are supposed to be deployed.

Assuming that we will eventually have file-based .py modules to deploy, what is the best way to keep FooOperation.py from one namespace out of the way of FooOperation.py in another?