-
Notifications
You must be signed in to change notification settings - Fork 421
Exception on import when AWS_PROFILE is invalid/null #294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@lorengordon this has to do with importing the xray core, which is then picking up the I would either unset
Or unset it before importing powertools in the tests import os
if "AWS_PROFILE" in os.environ:
del os.environ["AWS_PROFILE"] |
@michaelbrewer Of course, that's my workaround. When I first attempted to reproduce, I imported the xray core directly and it worked fine, so I thought it was something in this library. But I must have messed up the env, because now I am reproducing easily on that import. I'll open an issue on the xray sdk. Thanks!
|
I suppose it could be a feature request here, in the sense that I don't need or want xray right now. I am only using the logger. So it might be nice to gate the import to an explicit call to a powertools class/method... |
@heitorlessa is looking at lazy loading libraries |
100% and thanks @michaelbrewer for helping out. I'm not sure how I missed this issue in my notifications so apologies @lorengordon for not replying earlier. I've done some research on backwards compatible solutions that work for 3.6+ (what we support), and am scheduling next Friday to experiment and will keep you posted. Thanks for reporting it! |
@heitorlessa All good, the workarounds are viable for now. 3.6+ works for us. Feel free to close this if you have another tracking issue for lazy loading libraries... I opened another issue on the xray sdk to better understand why it needs to setup the session as a global, and impact imports like this... |
Awesome - I'll subscribe to that. I'll keep this open, and I'll try this method first as it seems clever enough to also prevent PyCharm/VSCode debugger to crash due to increased ref counting in getattr |
Nice, and it's very simple! I've got use cases for that in my own projects! 😂 |
As a pure hack, i have disabled the one i don't need during my unit testing import sys
from unittest.mock import Mock
mock = Mock()
sys.modules['aws_lambda_powertools.tracing']=mock
sys.modules['aws_lambda_powertools.metrics']=mock
sys.modules['aws_lambda_powertools.loggin']=mock |
hey @lorengordon - This will now be available in the next release. If you're not using Tracer, you should see a ~400ms+ perf improvement in cold start depending on your memory setting. Here's the aftermath using 128M memory: from ~620ms to ~50ms. BeforeAfter |
Wow, that's fantastic, thanks @heitorlessa! |
@heitorlessa @lorengordon and this also works without any errors ;) AWS_PROFILE= python -c 'import aws_lambda_powertools' |
This is now available in 1.11.0 - Literally just launched ;) 🎉 |
Expected Behavior
import aws_lambda_powertools
should still succeed even if the ENV containsAWS_PROFILE
with a bad value.Current Behavior
It appears that during import, under at least some conditions, aws_lambda_powertools will attempt to setup an aws client session? I'm not sure I understand why. So if the ENV contains an invalid AWS config, in particular
AWS_PROFILE=
orAWS_PROFILE=fakeprofile
, then the import fails with an exception. Which, yes, it's invalid, and I now that I knowaws_lambda_powertools
has this behavior I can work around it easily by unsetting the envs. But it still seems like it shouldn't be setting up a session on import?Possible Solution
Not sure on a solution, but a workaround is to make sure your development environment unsets bad AWS_ envs before attempting to run tests on your python code. :)
Steps to Reproduce (for bugs)
AWS_PROFILE= python -c 'import aws_lambda_powertools'
Environment
The text was updated successfully, but these errors were encountered: