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

[v3.0.0] Packaged version of Poetry incompatible with lock files generated by latest stable version. #79

Open
CRC-Mismatch opened this issue Mar 24, 2023 · 0 comments

Comments

@CRC-Mismatch
Copy link

CRC-Mismatch commented Mar 24, 2023

Our company has a "skeleton" template repository for bootstrapping new Serverless projects, and we've made it prepared by default for Python 3.9 with Poetry, including ready-made GitHub Actions workflows to deploy to staging and production using v3 of this action. We already had 3 projects running successfully with it, until this week, a new developer had to bootstrap a new project. He had to install his development environment from scratch, which included installing Python, Node.js and Poetry since he couldn't leverage Docker due to licensing issues (he's on Windows).

After getting the project ready and tested locally, he pushed his changes, and we started seeing the staging workflow fail while trying to generate the requirements.txt for packaging, with no more information than the following (even after adding --verbose to the job's command args and SLS_DEBUG=1 to the job's env-vars):

 Generating requirements.txt from poetry.lock

× Stack [redacted] failed to deploy (2s)
Environment: linux, node 14.21.3, framework 3.28.1, plugin 6.2.3, SDK 4.3.2
Credentials: Local, environment variables
Docs:        docs.serverless.com
Support:     forum.serverless.com
Bugs:        github.com/serverless/serverless/issues

Error:
Error: `poetry export --without-hashes -f requirements.txt -o requirements.txt --with-credentials` Exited with code 1
    at ChildProcess.<anonymous> (/github/workspace/node_modules/child-process-ext/spawn.js:38:8)
    at ChildProcess.emit (events.js:400:28)
    at ChildProcess.emit (domain.js:475:12)
    at maybeClose (internal/child_process.js:1088:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:296:5)

After a lot of messing around, I finally cloned the project to my own machine and attempted a top-down approach... I managed to get a local Docker execution of this repository's v3 image by using a dumbed down command line to finally fail with the same error - but it only happened with the new project. So I then attempted to run the poetry export --without-hashes -f requirements.txt -o requirements.txt --with-credentials by itself, and lo-and-behold, I finally got it to inform me that the lock file was generated by a newer version, and so my local Poetry was unable to use it. After digging some more, I noticed that the base image nikolaik/python-nodejs:python3.9-nodejs14-alpine used by the v3 version installs Poetry via pip with a hard-coded version 1.1.15. The new developer had freshly installed Poetry 1.4.1 using the official script, and my local setup has 1.2.0.

While the v3.1 version uses nikolaik/python-nodejs:python3.10-nodejs16-slim (which installs Poetry using their official install script), for now it also seems to fail to deploy Python 3.9 lambdas with other problems (due to AWS still not providing a stable Python 3.10 base image for Lambdas).

My suggestion would be to push Python 3.10 and Node 16 to a new v4 version, and release a v3.2 version using nikolaik/python-nodejs:python3.9-nodejs14-slim as base which should, in theory, make for the "best of both worlds" without having to add a notice to the action's documentation about the Poetry limitations for each version.

@CRC-Mismatch CRC-Mismatch changed the title Packaged version of Poetry incompatible with lock files generated by latest stable version. [v3.0.0] Packaged version of Poetry incompatible with lock files generated by latest stable version. Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant