Skip to content
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

Unable to import module 'wsgi_handler': No module named 'werkzeug' #469

Open
bibbycodes opened this issue Feb 20, 2020 · 16 comments
Open

Unable to import module 'wsgi_handler': No module named 'werkzeug' #469

bibbycodes opened this issue Feb 20, 2020 · 16 comments
Labels

Comments

@bibbycodes
Copy link

I keep getting this error in my AWS logs when trying to deploy using serverless:

Unable to import module 'wsgi_handler': No module named 'werkzeug'

It seems that the zip folder containing the app does not contain the right packages as specified in my requirements.txt and there is no .requirements folder either.

I have explicitly specified werkzeug in my requirements .txt and yet this package cannot be installed.

My serverless .yml:

service: serverless-flask
plugins:

  • serverless-python-requirements
  • serverless-wsgi
  • serverless-dynamodb-local
    custom:
    tableName: 'transactions-table-${self:provider.stage}'
    wsgi:
    app: app.app # entrypoint is app.app, which means the app object in the app.py module.
    packRequirements: false
    pythonRequirements:
    dockerizePip: true
    dynamodb:
    stages:
    • test
    • dev
      start:
      migrate: true

provider:
name: aws
runtime: python3.6
stage: dev
region: us-east-1
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:Query
- dynamodb:Scan
- dynamodb:GetItem
- dynamodb:PutItem
Resource:
- { "Fn::GetAtt": ["TransactionsDynamoDBTable", "Arn" ] }
environment:
TRANSACTIONS_TABLE: ${self:custom.tableName}

functions:
app:
handler: wsgi_handler.handler
events:
- http: ANY /
- http: 'ANY {proxy+}'
resources:
Resources:
TransactionsDynamoDBTable:
Type: 'AWS::DynamoDB::Table'
Properties:
AttributeDefinitions:
-
AttributeName: transactionId
AttributeType: S
-
AttributeName: timestamp
AttributeType: S
KeySchema:
-
AttributeName: transactionId
KeyType: HASH
-
AttributeName: timestamp
KeyType: RANGE
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
TableName: ${self:custom.tableName}
My requrements.txt :

boto3==1.11.17
botocore==1.14.17
Click==7.0
docutils==0.15.2
Flask==1.1.1
itsdangerous==1.1.0
Jinja2==2.11.1
jmespath==0.9.4
MarkupSafe==1.1.1
python-dateutil==2.8.1
s3transfer==0.3.3
six==1.14.0
urllib3==1.25.8
Werkzeug==1.0.0
Any ideas what I'm doing wrong here?

@revmischa
Copy link

Been seeing this too

@miketheman miketheman added the bug label Feb 22, 2020
@adamszeptycki
Copy link

same here...

@BenjaminWatts
Copy link

Same here

@4lph4-Ph4un
Copy link

The same!

@AndrewFarley
Copy link
Collaborator

AndrewFarley commented Mar 28, 2020

logandk/serverless-wsgi#80

Can you guys rollback and version pin your version of serverless wsgi and make sure to be using the latest version of this plugin and try again? I suspect it is the plugin. I will do some testing of my own shortly.

@4lph4-Ph4un
Copy link

Mine was a false alarm, provided by not pointing to the correct requirements.txt, so all clear here even with the new version.

@Csanchezz
Copy link

did somebody find a way to fix this?

@eml-nx
Copy link

eml-nx commented May 19, 2021

I found this in stackoverflow and it works I downgrade Flask to 1.1.4

Flask, Werkzeug and other pallets projects just had a major update, dropping python2 support and deleting _compat module. And AWS has't resolve the capability issue yet.
The simplest fix will be downgrading Flask, Werkzeug, etc. to the previous major version.

Credits to Allan Chain

@kevincerro
Copy link

kevincerro commented May 23, 2022

For anyone here, this is solved since version 2.0.0.

Run sls plugin install -n serverless-wsgi on your terminal inside your project folder.
(At this moment, these command installs 3.0.0 version)

@mohammad-aqajani
Copy link

mohammad-aqajani commented Jul 12, 2022

(take care this message means that aws lambda does not load any packages as layer)

for mine:
1- docker installed
2- create requirements.txt
3- reduce serverless framework version from 5.x to 4.x

Output:
Deploying eve-api to stage dev (us-east-1)
Using Python specified in "runtime": python3.8
Packaging Python WSGI handler...
Generated requirements from path/to/requirements.txt in path/to/repo/.serverless/requirements.txt...
Installing requirements from path/to/repo/.serverless/requirements/requirements.txt ...
Running ...
Injecting required Python packages to package...

@victorstefan13
Copy link

Facing the same issue, anyone found a solution?

@pgrzesik
Copy link
Collaborator

Could you share more context about your specific setup @victorstefan13? Are you using Flask or a similar framework? If yes, what version?

@victorstefan13
Copy link

So I managed to fix this. I think the issue was actually related to our deployment pipelines. I went down the route of pre-packing the app by creating a package directory and installing the python requirements within that directory - pip install -r requirements.txt -t package --no-deps --no-binary pydantic, copying my app to that directory and zipping the folder. Then in the serverless.yml file I specified the zipped package with artifact: package.zip. Thanks for your help!

@alex-morgun
Copy link

alex-morgun commented Jul 4, 2024

Bug Report: Serverless Offline Missing WSGI Files

Title: sls offline fails to create required WSGI files

Severity: High

Environment:

  • Serverless Framework version: 4
  • OS: Linux
  • Python version: 3.8

Description:
sls offline doesn't create files, which are necessary for WSGI applications.

Steps to Reproduce:

  1. Run sls deploy
  2. Run sls offline
  3. Observe missing files

Expected: sls offline creates required WSGI files
Actual: Files are not generated

Workaround:
Run sls wsgi install && sls offline

@pgrzesik
Copy link
Collaborator

Hey @alex-morgun - that should probably be reported within serverless-offline repository, unless you're certain that there's a bug within serverless-python-requirements plugin.

@alex-morgun
Copy link

Hey @alex-morgun - that should probably be reported within serverless-offline repository, unless you're certain that there's a bug within serverless-python-requirements plugin.

Hello, thanks, this is number one link in a google, so this is a way how to fix it. It's not an actual issue filled. Bu t thanks for an idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests