source `.env` into `.environment` ?

[gilzow]

Working on the flask framework quickstart and using it to test (platform|upsun)ify.
Flask (as well as several of the other frameworks) support, and possibly come with, a .env file. Does it make sense for us to source this file in our generated .environment file if a .env file exists?

[akalipetis]

I don't think that's a good idea - most of the projects I've seen have .env commented out and the ones that don't, they usually use it as an example for the environment to use during development.

This might be a breaking change and potentially hard to debug as this will override any variables set through the UI or elsewhere.

What do you think?

[gilzow]

This might be a breaking change and potentially hard to debug as this will override any variables set through the UI or elsewhere.

Since we're discussing {paas}ify this shouldn't be a breaking change because users aren't going to typically {paas}ify an existing, already deployed application. My understanding is that {paas}ify is targeted for new, not-yet-deployed projects? Also, variables set in the UI are currently overwritten if a user sets the same variable in a .environment file or as

variables:
    env:

in the project config file so this isn't shouldn't be a breaking change in that regard.

The reasoning for my suggestion is that many projects use .env files to set common, good values for an application, that then can be overridden for a specific environment. As an example, in this flask app I've been testing, it sets

FLASK_APP=autoapp.py

which then flask uses to know which module to load at flask run and referenced when using gunicorn. If a user comes to our services, has committed a .env file, they may incorrectly assume that we'll parse that file for them like on other systems. They then will have to manually add those items from their .env file into .environment or into the config file after the app fails to work.

We have a similar issue with laravel to the point that the laravel-bridge was built to make things smoother.

I have a couple of thoughts on how we could tackle this:

• The easiest would be if a .env file is present to warn the user (ideally with links to docs) that we do not load .env files and that anything defined in them will not be available when deployed and will need to be added in another method.

• Another idea (after conversing some more with @chadwcarlson ) would be to load the .env file and for each line, write the line back out into the .environment file as a comment, with export prepended (using the FLASK_APP item above as an example, we would write it into .environment as # export FLASK_APP=autoapp.py) and then inform the user what we've done and that if they want the values to be used, they need to uncomment.

• Another idea, I believe initially proposed by @lolautruche - and my current favorite - is to let the user define what files we'll source for them with corresponding entries in the config file.