Allow customization via single user controllable file about pilothouse HOT 13 CLOSED

After some investigation of the ability to use JSON, I think we may be better off using a simple .env type file instead.

JSON parsing would require a dependency that could prove difficult to distribute with this tool, whereas parsing a simple key / value text .env file would be much easier.

For example a possible solution: http://stackoverflow.com/a/34093548/1181865

from pilothouse.

Actually it's much easier than that (in fact that was accomplishing the wrong thing):

The .config file might look like:

PHP_POST_MAX_SIZE="123M"
PHP_UPLOAD_MAX_FILE_SIZE="104M"

And in dockerbox.sh:

source .config

echo $PHP_POST_MAX_SIZE

from pilothouse.

Proposing the name of the configuration file to be: dockerbox.ini.

I think it stands to reason that it should not be a hidden file as this is something the user should normally be able to see / edit.

I further think that the typical .env which stands for 'environment' doesn't make much sense here. We are not setting up a project which would require different 'environments'. Rather we are configuring / initializing user settings for a system (akin to customizing php or nginx).

from pilothouse.

Since the docker compose is what needs these, this will probably require a separate script to write the custom values to the config files or bring them in temporarily for the build.

from pilothouse.

Noting that we can actually use environment variables to populate values in the docker-compose file: https://docs.docker.com/compose/environment-variables/#/substituting-environment-variables-in-compose-files

from pilothouse.

Oh very cool

from pilothouse.

Infrastructure for user-configurable settings is now in place, see dockerbox-zz/dockerbox@5820574#diff-86aa6485c58b4fc1f20493ab5339a2cdR496

I've started off by allowing for a custom sites directory, by placing something like the following in dockerbox.ini:

SITES_DIR="~/Dev/sites"

Now that this is in place, we can begin working through the other issues listed above.

from pilothouse.

Noting that docker-compose does allow defining of variables via a .env file, but those variables only apply to the docker-compose.yml file and the file would need to be parsed in order to be used in the dockerbox command, which would add unnecessary complexity. Thus, I'm defining all defaults inside the dockerbox command itself, so they can easily be used both within the command and in the compose file.

While I'm using the .env file to define the project name (which will allow the parent directory to be renamed without losing all existing containers), I'm not using the .env file for any user-configurable variables.

from pilothouse.

Amazing work this is awesome!

Thanks Philip!

from pilothouse.

How should we modify values that only get used by the docker-compose file and not the dockerbox script?

from pilothouse.

I'm fine with defining those values in the dockerbox script along with the others, to keep everything organized in one place. It doesn't really matter that the value is only used in the docker-compose file.

from pilothouse.

Why don't you start it off, I'm not sure where / how it should do that in the dockerbox script in order to receive the custom values in the docker-compose step

from pilothouse.

@AaronHolbrook here's an example of adding variables to the dockerbox script: dockerbox-zz/dockerbox@64ba29a

While in this example I'm not using them in the docker-compose file, the procedure is the same and they are available in docker-compose if I would want to use them.

from pilothouse.