You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've followed the instructions on the plugin page and am getting an error that there's no such module as _lumigo.
I tried installing a few previous versions and it doesn't look like the lumigo python-tracer package (distributed as lumigo-tracer) has ever shipped this name, so I suspect the problem isn't that the import name has changed, but that the import command is meant to be doing something else.
{
"errorMessage": "Unable to import module '_lumigo/pypi_release_check': No module named '_lumigo'",
"errorType": "Runtime.ImportModuleError",
"requestId": "4d7f20d8-970a-433f-9317-6f504438b5a4",
"stackTrace": []
}
I suspect the problem may be due to my project structure: I have a serverless.yml and below it I have directories containing Python packages (subservices) deployed in a single service as one stack.
My guess is that this has resulted in the tracer trying to import them from the wrong location.
I haven't read the source closely enough to be sure but if it's looking in the service directory and then assuming to find the service there, i.e. assuming that the handler must be at the top level. In my case the handler is down a level (there's a dotname that goes subpackage.module.funcdef rather than module.funcdef).
I copied the serverless config down a level and adjusted, and packaged there, and can see that when I enable the sls lumigo plugin I get the following code:
I suspect this would work if the _lumigo directory created in the packaged zip were dropped down a level so that it ends up being within the bounds of where the individual subpackages can "see" (when the Python runtime is invoked on a subpackage it necessarily limits the parent folder which is "visible" to import from, and I think that's what you're relying on here to make the wrapper work).
Annoying because I can see the handler wrapper is right there, hopefully it will be a simple fix ! :-)
For clarity my "subservice" tree below my src directory containing serverless.yml is:
Note that I un/commented out the package: include/exclude statements here to see if they were involved, this is used to achieve individual package separation in this project layout. I commented it out just to be able to see what was going on. It doesn't affect the result.
When I put the following serverless.yml file in the pypi_watcher directory I could see a _lumigo directory in the packaged zip (specifically the function zip pypi_release_check.zip):
I've followed the instructions on the plugin page and am getting an error that there's no such module as
_lumigo
.I tried installing a few previous versions and it doesn't look like the lumigo python-tracer package (distributed as
lumigo-tracer
) has ever shipped this name, so I suspect the problem isn't that the import name has changed, but that the import command is meant to be doing something else.I suspect the problem may be due to my project structure: I have a
serverless.yml
and below it I have directories containing Python packages (subservices) deployed in a single service as one stack.My guess is that this has resulted in the tracer trying to import them from the wrong location.
I haven't read the source closely enough to be sure but if it's looking in the service directory and then assuming to find the service there, i.e. assuming that the handler must be at the top level. In my case the handler is down a level (there's a dotname that goes
subpackage.module.funcdef
rather thanmodule.funcdef
).I copied the serverless config down a level and adjusted, and packaged there, and can see that when I enable the sls lumigo plugin I get the following code:
I suspect this would work if the
_lumigo
directory created in the packaged zip were dropped down a level so that it ends up being within the bounds of where the individual subpackages can "see" (when the Python runtime is invoked on a subpackage it necessarily limits the parent folder which is "visible" to import from, and I think that's what you're relying on here to make the wrapper work).Annoying because I can see the handler wrapper is right there, hopefully it will be a simple fix ! :-)
For clarity my "subservice" tree below my
src
directory containingserverless.yml
is:and I'm using the
functions.yml
to define functions for the service above it:where the
functions.yml
file contains:package: include/exclude
statements here to see if they were involved, this is used to achieve individual package separation in this project layout. I commented it out just to be able to see what was going on. It doesn't affect the result.When I put the following
serverless.yml
file in thepypi_watcher
directory I could see a_lumigo
directory in the packaged zip (specifically the function zippypi_release_check.zip
):The text was updated successfully, but these errors were encountered: