Support configurable PHP extensions

[judgej]

Some hints here on how to set them up:

https://hub.docker.com/_/php

[judgej]

I'm newish to docker, so bear with me.

To customise a docker image, a new image needs to be built from a docker file, then that docker file run. Always the two steps:

docker build -t foo . && docker run -it foo

So docker build will build the Docker file in ., then tag it as foo, then run the tagged image foo.

So each project could have different settings, and so different Docker files, and so different images. That means each project needs a different tag. The tag should be randomly generated and added to the project config so it is used over and over. Suggestion: if the containers are unque to the settings, then why not use a hash of the settings for the tag?

We would like a default docker file to be up and running quickly and to be able to serve as an example. That could be a stub that gets copied to somewhere else when this package is installed, and that copy can be customised, and can be saved to the project repo if desired. The stubs would only be copied to their customisable destination if that destination does not already exist.

A package such as Laravel sail has a setup artisan command. This package is not just for Laravel, so is going to have to handle the initital setup by itself.

[judgej]

Ah, scripts can be run on install to set files u. See: https://getcomposer.org/doc/articles/scripts.md#defining-scripts

Update: this will not work. The docs says it only works in the root. It means it only works if the scripts are set in the root composer file, not if the scripts are set in a root package, i.e. not a dependent package.

[judgej]

A Symfony Conole command (https://symfony.com/doc/current/console.html) could be used for interacting with the package, installing the config and customisable Docker files for example. It has quite a few dependencies involved, but for Laravel and Symfony projects at least, those dependencies are likely to already be there.

It should be noted that the container this package is installed and initiailised in, is not the same container that the package provides, and could be different versions of PHP even. However, this package would be in the same codebase as the running code, so they should be the same version. Making the PHP versions the same would be the first assumption the initialisation of the container makes.