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
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.
The text was updated successfully, but these errors were encountered:
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
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 andSLS_DEBUG=1
to the job's env-vars):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 thepoetry 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 imagenikolaik/python-nodejs:python3.9-nodejs14-alpine
used by thev3
version installs Poetry viapip
with a hard-coded version1.1.15
. The new developer had freshly installed Poetry1.4.1
using the official script, and my local setup has1.2.0
.While the
v3.1
version usesnikolaik/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 av3.2
version usingnikolaik/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.The text was updated successfully, but these errors were encountered: