feat: Add poetry-core support

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm

[ZPascal]

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

[ramonskie]

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]

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

[ZPascal]

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]

#1182 adds poetry-core to the manifest.yml

[ramonskie]

lgtm