What are you trying to do?
I'd like to separate the download phase from the build/install phase so that extension installation can be performed without network access.
This is useful for Docker/BuildKit builds where only specific build steps are allowed network access. For example:
- Download all required artifacts while networking is enabled.
- Disable networking (
RUN --network=none).
- Build and install the extension entirely from the previously downloaded artifacts.
This is similar to how package managers like apt support --download-only and --no-download.
What platform, and PIE version are you using?
pie show -v
🥧 PHP Installer for Extensions (PIE) 1.4.9, from The PHP Foundation
You are running PHP 8.3.33
Target PHP installation: 8.3.33 nts, on Linux/OSX/etc x86_64 (from /usr/bin/php8.3)
Using pie.json: /root/.config/pie/php8.3_8e7fcd745470cd568cb685b6efc26480/pie.json
Using pie.json: /root/.config/pie/php8.3_8e7fcd745470cd568cb685b6efc26480/pie.json
Tip: to include extensions in this list that PIE does not manage, use the --all flag.
Loaded PIE extensions:
(none)
Steps to reproduce the issue
Currently the only available workflow is:
pie install phalcon/cphalcon:5.17.0
This combines:
- dependency resolution
- metadata retrieval
- downloading
- building
- installation
There doesn't appear to be a way to perform the download separately and later install using only locally cached artifacts.
What do you expect to happen?
It would be great if PIE supported an offline-friendly workflow, for example:
pie download phalcon/cphalcon:5.17.0
pie install --offline phalcon/cphalcon:5.17.0
or alternatively:
pie install --download-only phalcon/cphalcon:5.17.0
pie install --no-download phalcon/cphalcon:5.17.0
The second command should fail if any required artifact is missing from the local cache, rather than attempting network access.
I don't have a strong preference for the exact command-line interface; the important capability is separating "fetch" from "build/install".
What is actually happening
pie install always performs downloading and installation as a single operation, making it difficult to build extensions in environments where network access is intentionally restricted after dependencies have been fetched.
Complete logs/output
N/A
Anything else?
This would improve support for:
- reproducible builds
- hermetic/offline builds
- Docker BuildKit (
RUN --network=none)
- CI environments with restricted or controlled egress
- build systems that separate dependency fetching from compilation
I believe this would make PIE fit well into modern container build workflows while also improving build reproducibility.
What are you trying to do?
I'd like to separate the download phase from the build/install phase so that extension installation can be performed without network access.
This is useful for Docker/BuildKit builds where only specific build steps are allowed network access. For example:
RUN --network=none).This is similar to how package managers like
aptsupport--download-onlyand--no-download.What platform, and PIE version are you using?
Steps to reproduce the issue
Currently the only available workflow is:
This combines:
There doesn't appear to be a way to perform the download separately and later install using only locally cached artifacts.
What do you expect to happen?
It would be great if PIE supported an offline-friendly workflow, for example:
or alternatively:
The second command should fail if any required artifact is missing from the local cache, rather than attempting network access.
I don't have a strong preference for the exact command-line interface; the important capability is separating "fetch" from "build/install".
What is actually happening
pie installalways performs downloading and installation as a single operation, making it difficult to build extensions in environments where network access is intentionally restricted after dependencies have been fetched.Complete logs/output
N/A
Anything else?
This would improve support for:
RUN --network=none)I believe this would make PIE fit well into modern container build workflows while also improving build reproducibility.