Skip to content

feat: Add poetry-core support#1181

Open
ZPascal wants to merge 1 commit intocloudfoundry:masterfrom
ZPascal:add-poetry-core-support
Open

feat: Add poetry-core support#1181
ZPascal wants to merge 1 commit intocloudfoundry:masterfrom
ZPascal:add-poetry-core-support

Conversation

@ZPascal
Copy link
Copy Markdown

@ZPascal ZPascal commented Apr 22, 2026

Add poetry-core bootstrap support for offline/vendored Python app deployments

Problem

When deploying a Python application with vendored dependencies (sdists) to Cloud Foundry, the buildpack fails with:

pip._vendor.pyproject_hooks._impl.BackendUnavailable: Cannot import 'poetry.core.masonry.api'

This happens because modern Python packages declare their build-time dependencies in pyproject.toml according to PEP 517. For example, flask-healthz declares:

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

When pip installs a package from a source distribution (sdist) online, it automatically downloads and installs any declared build backends. In an offline/vendored deployment (--no-index), pip cannot fetch them — and since pip 23.1 enforces PEP 517 strictly (no longer falling back to the legacy setup.py install method), the build fails entirely.

Root Cause

The buildpack's InstallCommonBuildDependencies() function already bootstraps setuptools/wheel (used by Click, CacheLib, etc.). However, poetry-core — used by flask-healthz and other Poetry-managed packages — was not handled.

poetry-core cannot be added to the app's vendor/ directory as a workaround because pip treats vendor/ as runtime dependencies to install, not as build backends to invoke during the build process.

Solution

Ship poetry-core as a normal buildpack dependency, just like the other packaged dependencies. The tarball still lives inside the buildpack, but it is now declared in manifest.yml and installed through Installer.InstallOnlyVersion("poetry-core", "/tmp/common_build_deps") before the bootstrap install:

pip install /tmp/common_build_deps --no-build-isolation

This keeps poetry-core on the standard manifest/installer path instead of special-casing manual tar extraction in supply.go.

After these steps, pip can successfully build any app sdist that uses flit-core, setuptools, or poetry-core as its build backend — fully offline.

Testing

Verified with a Flask application using all-sdist-vendored dependencies, including flask-healthz==1.0.1. All 13 packages installed successfully from source during staging with no internet access to PyPI.

Dependecy

Depends on cloudfoundry/buildpacks-ci#621 & #1156

Fix

#165

Copy link
Copy Markdown
Contributor

@ramonskie ramonskie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
the reason for the different instalation method is explained within the pr description.
but maby we also need a small description within the code here

@ramonskie
Copy link
Copy Markdown
Contributor

#1156 needs to be fixed after we merge this as poetry-core is hardcoded there

@ZPascal
Copy link
Copy Markdown
Author

ZPascal commented Apr 22, 2026

lgtm the reason for the different instalation method is explained within the pr description. but maby we also need a small description within the code here

Please do not merge it yet. I'll place a comment in the code.

@ramonskie ramonskie mentioned this pull request Apr 22, 2026
3 tasks
@ramonskie
Copy link
Copy Markdown
Contributor

#1182 adds poetry-core to the manifest.yml

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

Successfully merging this pull request may close these issues.

2 participants