php cli is not in $PATH

[till]

Expected Behavior

I can use the php cli inside my image:

<?php
#!/usr/bin/env php
echo "Hello world";

Current Behavior

/layers/paketo-buildpacks_php-dist/php/bin/php -v
PHP 8.1.7 (cli) (built: Jun 15 2022 09:21:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.7, Copyright (c) Zend Technologies
cnb@c2a50c734a25:/workspace$ echo $PATH
/cnb/process:/cnb/lifecycle:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
cnb@c2a50c734a25:/workspace$ php -v
bash: php: command not found

Possible Solution

Add the layer to the PATH, or install in a location that is in PATH already.

Steps to Reproduce

Discovered this while fiddling with paketo-buildpacks/composer-install#46

Motivations

Lots of projects distribute command line tools that rely on the php (cli) to be in PATH. These are broken now.

In addition, there are so-called phars, which are php apps distributed as an executable archive. They also rely on the cli to be in PATH.

[sophiewigmore]

php is made available in PATH during the build, and at launch-time so it's available to other buildpack processes. You can see it if you built a PHP app with the buildpacks, and then overwrite the start command when starting the container like so:

 docker run -it --entrypoint launcher <image name> env

You're right that it's not available on the final image. Your reasoning for including it seems reasonable though. Could you possibly provide a more concrete example of an app which needs access to PHP on the final image?

[till]

You're right that it's not available on the final image. Your reasoning for including it seems reasonable though. Could you possibly provide a more concrete example of an app which needs access to PHP on the final image?

Most frameworks come with a console component which runs on the CLI to run, e.g. to generate assets, setup caches, houskeeping tasks, etc.. In order for them to run, most have a shebang such as:

https://github.com/laravel/vapor-cli/blob/c4d8c043372bcb7409060be3b36dbbd62fcfb879/vapor#L1

[thitch97]

@till could you provide some more concrete reproduction steps for this issue? I see your PR but I'm still a bit confused about why it's necessary. The lifecycle should automatically add the bin directory within the PHP layer to the path and so far I'm able to use the php CLI in a pack-built app image just fine.

[till]

@thitch97 It's not in the launch environment though. So php console applications don't run. Am I missing something?

[thitch97]

@till How were you trying to invoke the app/inspect the launch environment? I'm able to use the CLI and see <layer>/php/bin on the PATH this way:

 ‣ docker run -it --entrypoint=launcher <app-image-name> /bin/bash
cnb@b47d1c5e5128:/workspace$ php -v
PHP 8.0.23 (cli) (built: Sep  1 2022 14:21:28) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.23, Copyright (c) Zend Technologies
cnb@b47d1c5e5128:/workspace$ env | grep PATH
LD_LIBRARY_PATH=/layers/paketo-buildpacks_php-dist/php/lib
PATH=/layers/paketo-buildpacks_php-dist/php/sbin:/layers/paketo-buildpacks_php-dist/php/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

The --entrypoint=launcher bit might be what you're missing

[robdimsdale]

I was able to shell out to the php CLI from within a sample app as follows:

app.php:

<?php
#!/usr/bin/env php
echo "Hello world";
?>

Procfile:

web: php app.php

Build and run the app with:

❯ pack build --builder paketobuildpacks/builder:full php-cli-app
❯ docker run -it php-cli-app
Hello world

I know this is using the full php buildpack, not just php-dist in isolation, but I think it demonstrates that the php buildpack supports applications which shell out to the CLI.

[till]

Thanks, that got me on the right track. Sorry for the noise, so much to learn. 🙈
https://github.com/till/php-buildpack-console-example

What are the situations where the launcher is used? Interactive sessions?

As in, I see the following in the image's ENTRYPOINT:

❯ docker inspect php-console| jq -r '.[0].Config.Entrypoint'
[
  "/cnb/process/web"
]

[robdimsdale]

@till this is a little confusing (at least to me) but I'll try to explain it as I understand it.

The launcher always runs by default when you run a process that is defined in the app. It sets up the environment and invokes the process.

The process types are defined by the buildpack process. In the example I gave above, you can see there is one process:

> pack inspect php-cli-app
Inspecting image: php-cli-app

REMOTE:
(not present)

LOCAL:

Stack: io.buildpacks.stacks.bionic

Base Image:
  Reference: 31e47455d34bd20756acc7261be7261de49bdf32894ba93a05234fa1ac088e39
  Top Layer: sha256:906c4e2df0d86adac183022dec5b1424999ef43acb55db5618cd6fad35d0f8df

Run Images:
  index.docker.io/paketobuildpacks/run:full-cnb
  gcr.io/paketo-buildpacks/run:full-cnb

Buildpacks:
  ID                                          VERSION        HOMEPAGE
  paketo-buildpacks/php-dist                  1.1.0          https://github.com/paketo-buildpacks/php-dist
  paketo-buildpacks/php-builtin-server        0.3.1          https://github.com/paketo-buildpacks/php-builtin-server
  paketo-buildpacks/procfile                  5.4.0          https://github.com/paketo-buildpacks/procfile

Processes:
  TYPE                 SHELL        COMMAND            ARGS        WORK DIR
  web (default)        bash         php app.php                    /workspace

If you want to run a command that isn't defined in the process list, you can do that, but the launcher won't be run unless you explicitly ask for it with --entrypoint=launcher.

There is more information on the launcher and process types on the official documentation.

[till]

Thanks for all the help with this. I am closing this as it works.