Composer docs/bugs (clarification)
See original GitHub issue(I’m using buildpack 4.3.77)
I’m trying to overcome a couple challenges deploying a PHP application to a CF PaaS (PWS).
I find your use of composer and related docs a little confusing:
By default, the PHP buildpack uses the composer.json and composer.lock files that reside inside the root directory, or in the directory specified as WEBDIR in your options.json. If you have composer files inside your app, but not in the default directories, use a COMPOSER_PATH environment variable for your app to specify this custom location, relative to the app root directory. Note that the composer.json and composer.lock files must be in the same directory.
COMPOSER_PATH
is not mentioned in the table before. It would be great to get more detail if this is a leftover from another time or e.g. if this a separate var to point the buildpack to, to store composer.json
(and .lock
).
Also, is there history available what this means: “if you have composer files inside your app”.
I am confused by this statement, because — where else would they be? Composer keeps dependencies local to the application (usually). So this means, vendor/
should be within the application, not somewhere else.
What is the reason for default lib/vendor/
with this buildpack? Most code seems to expect vendor/
? Most projects/frameworks follow a pattern where:
lib/ (sometimes called src/)
public/ (or web/ or www/)
vendor/
I realise there are (still) exceptions to this and people still put all their code in a “public” directory, but working around it like this, defeats the purpose of the buildpack to e.g. run a demo application.
I tried to use COMPOSER_INSTALL_OPTIONS
:
{
"COMPOSER_INSTALL_OPTIONS": "--no-interaction --no-progress",
"COMPOSER_VENDOR_DIR": "vendor",
"WEBDIR": "public"
}
This led to:
Invalid argument - - n o - i n t e r a c t i o n - - n o - p r o g r e s s. Use "composer require - - n o - i n t e r a c t i o n - - n o - p r o g r e s s" instead to add packages to your composer.json.
(Edit: I guess this should be a list.)
Maybe not in scope of this buildpack — is there a validator for everything in .bp-config/options.json
)? E.g. pre-push, so I don’t have to dig around in the buildpack’s code to figure this out?
Happy to send a PR with doc fixes or discuss further.
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (1 by maintainers)
@dmikusa-pivotal So I “pack” my app, add to Dockerhub and then change my manifest to use the docker image? I’ll see if I can try that on the weekend.
The Buildpack does the opposite right now though. It’s not turn-key, as it requires configuration for the majority of all PHP frameworks and demo applications. Best practice is not to rely on
include_path
anymore as composer encourages local dependencies (scoped within the app) and provides optimised autoloaders which…Examples (which expect
$APPROOT/vendor
):Search for more on Github — they all have
(/)vendor
in.gitignore
.If you follow a pattern where you have scripts in a
bin/
folder, then most of these don’t work out of the box, as they../vendor/autoload.php
. That’s why most Symfony examples for Cloud Foundry disable/customizepost-install-cmd
. Not because the scripts don’t work, but because their invocation is broken by default (and I just happen to spend more time on trying to figure it out).It’s great that the bp allows flexibility (even if I don’t see any merit), but this is using the opposite of what you should be the standard by introducing this
lib/vendor
thing.