Code Monkey home page Code Monkey logo

parameterhandler's Introduction

Managing your ignored parameters with Composer

This tool allows you to manage your ignored parameters when running a composer install or update. It works when storing the parameters in a Yaml file under a single top-level key (named parameters by default). Other keys are copied without change.

CI Latest Stable Version Latest Unstable Version

Usage

Add the following in your root composer.json file:

{
    "require": {
        "incenteev/composer-parameter-handler": "~2.0"
    },
    "scripts": {
        "post-install-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters"
        ],
        "post-update-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters"
        ]
    },
    "extra": {
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        }
    }
}

The app/config/parameters.yml will then be created or updated by the composer script, to match the structure of the dist file app/config/parameters.yml.dist by asking you the missing parameters.

By default, the dist file is assumed to be in the same place than the parameters file, suffixed by .dist. This can be changed in the configuration:

{
    "extra": {
        "incenteev-parameters": {
            "file": "app/config/parameters.yml",
            "dist-file": "some/other/folder/to/other/parameters/file/parameters.yml.dist"
        }
    }
}

The script handler will ask you interactively for parameters which are missing in the parameters file, using the value of the dist file as default value. All prompted values are parsed as inline Yaml, to allow you to define true, false, null or numbers easily. If composer is run in a non-interactive mode, the values of the dist file will be used for missing parameters.

Warning: This parameters handler will overwrite any comments or spaces into your parameters.yml file so handle with care. If you want to give format and comments to your parameter's file you should do it on your dist version.

Keeping outdated parameters

Warning: This script removes outdated params from parameters.yml which are not in parameters.yml.dist If you need to keep outdated params you can use keep-outdated param in the configuration:

{
    "extra": {
        "incenteev-parameters": {
            "keep-outdated": true
        }
    }
}

Using a different top-level key

The script handler looks for a parameters key in your dist file. You can change this by using the parameter-key param in the configuration:

{
    "extra": {
        "incenteev-parameters": {
            "parameter-key": "config"
        }
    }
}

Using environment variables to set the parameters

For your prod environment, using an interactive prompt may not be possible when deploying. In this case, you can rely on environment variables to provide the parameters. This is achieved by providing a map between environment variables and the parameters they should fill:

{
    "extra": {
        "incenteev-parameters": {
            "env-map": {
                "my_first_param": "MY_FIRST_PARAM",
                "my_second_param": "MY_SECOND_PARAM"
            }
        }
    }
}

If an environment variable is set, its value will always replace the value set in the existing parameters file.

As environment variables can only be strings, they are also parsed as inline Yaml values to allows specifying null, false, true or numbers easily.

Renaming parameters

If you are renaming a parameter, the new key will be set according to the usual routine (prompt if possible, use environment variables, use default). To have the parameters handler use the value of an (obsolete) parameter, specify a rename-map:

{
    "extra": {
        "incenteev-parameters": {
            "rename-map": {
                "new_param_1": "old_param_1",
                "new_param_2": "old_param_2"
            }
        }
    }
}

This will create the new parameters new_param_1 and new_param_2 while using the values from old_param_1 and old_param_2, respectively. It will not remove the old parameters unless you've also removed them from the dist version.

If the old parameter is no longer present (maybe because it has been renamed and removed already), no parameters are overwritten. You don't need to remove obsolete parameters from the rename map once they have been renamed.

Managing multiple ignored files

The parameter handler can manage multiple ignored files. To use this feature, the incenteev-parameters extra should contain a JSON array with multiple configurations inside it instead of a configuration object:

{
    "extra": {
        "incenteev-parameters": [
            {
                "file": "app/config/parameters.yml",
                "env-map": {}
            },
            {
                "file": "app/config/databases.yml",
                "dist-file": "app/config/databases.dist.yml",
                "parameter-key": "config"
            }
        ]
    }
}

parameterhandler's People

Contributors

alcaeus avatar cordoval avatar derrabus avatar elnur avatar fabpot avatar franmomu avatar gnugat avatar h4cc avatar igorzoriy avatar ivan1986 avatar j-d avatar jordillonch avatar lsmith77 avatar lucascourot avatar pborreli avatar rgazelot avatar richsage avatar rosier avatar rybakit avatar sgilberg avatar soullivaneuh avatar stof avatar w0rma avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

parameterhandler's Issues

non interactive mode

for integration with vagrant it would be useful to have a way to dynamically use a non interactive mode. not sure if composer even supports passing on parameters it doesnt know to handlers.

composer hangs up

Hi,

On a existing project with existing parameter files my composer calls the ParameterUpdater and then does nothing more.
With a fresh project is asks for input (works fine).

Part from composer.json

        "post-install-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ]

Output

$ php composer.phar install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
Updating the "app/config/parameters.local.yml" file

Thats it. Nothing more happens.

Symlinked files are not followed / always replaced

When there is a symlink in place e.g. app/config/parameters.yml -> /somewhere/shared/config/env-parameters.yml, the symlink is removed and replaced by a file generated from scratch.

Wouldn't it make sense if it followed the symlink and treated content as content to matter where in the filesystem the eventual file happens to reside?

Null values from environment variables

Right now, environment variables are only interpreted as null when their values are "null" (as a string).

FOO_BAR=null

Can you consider using the empty string too ?

FOO_BAR=

get a random paramter value by default to avoid collision

In our company, we use the following setup.

A development server where different developers work on different or same projects.

We have a symfony application which uses elastic search (one elastic search server for all developers)
Every working copy has its own index in elasticsearch_index_name

for now we use a convention like: PROJECT-NAME_DEVELOPER-NAME, so the index of my working copy is named:
elasticsearch_index_name: SYMFONY_OSKARSTARK

I can't write this to my parameters.yml.dist:
elasticsearch_index_name: SYMFONY

But in my case the name is irrelevant (a hash would be great, or a timestamp), is there a possibility to generate a random string or a timestamp to avoid this collision, if a developer just enter through the interactive questions for the parameters?

I hope you understand my problem!

Best regards Oskar

Inconsistent backslash escaping in parameter values

I have a parameters.yml file with the following line:

parameters:
    client_files_dir: "D:\software\client-files"

After the parameter handler (v2.1.0) runs it becomes this:

parameters:
    client_files_dir: "D:\software\\client-files"

I'm not sure if that backslash escaping should occur at all, but it's at least inconsistent as the first backslash is left alone and the second one is escaped.

Add support for instructional comments per file

At the moment when running the buildParameters script you get this advice:

Creating the "<file>" file
Some parameters are missing. Please provide them.

A nice to have to be able to configure the output per file. E.g.:

  "extra": {
    "incenteev-parameters": [
      {
        "file": "file.yml",
        "comment": "Login to your account and provide the API credentials here",
        ...
     }
    ]
  }
'''

Handle constants from .dist

I have a use case where the mcrypt cipher and mode are stored into the .dist file.

parameters:
    cipher: !php/const:MCRYPT_RIJNDAEL_128
    mode: !php/const:MCRYPT_MODE_CBC

After the build of the parameters.yml file, these two keys are set to null.

I can submit a PR to correct that case but I just wanted to know your opinion about this issue.

Regards,

ProcessorInterface and custom processors

The idea is to make a processor interface and make possibility to give a custom processor to run.

In my case, I have some parameters like binaries paths.

Having a custom processor will allow me to auto-detect paths and put them to the configuration file.

Update parameters based on vcs-status

I'm using Assetic in combination with compass and uglifycss to manage my assets. One of the configuration parameters of Assetic is assets_version in order to handle cache busting.

It would be nice if the ParameterHandler could update a parameter based on the current revision of a version control system (like svn or git). That would result in cache busting based on the code version, and would not bust the cache in case the code hasn't been updated but just some composer packages are updated.

Extracting the ScriptHandler's logic for usage outside of composer

I was wondering if there would be a way to extract the logic of the composer's ScriptHandler into another class (or maybe a Symfony2 command ?), so that it can be used outside of composer.

I am deploying my application to a server having complete network restriction (so it's impossible to use composer install during the deployment), so we have deploy branches containing the vendors. However, we do not have the parameters.yml file in it as its configuration differ on the server, and we often find ourselves deploying the application with new parameters and having issues because the parameters are not updated beforehand.

If this logic could be extracted, we would be able to execute it before executing any command on the newly deployed application, and therefore avoiding errors.

What do you think?

Error while updating

Hello,

I'm updating a current installation of Symfony from version 2.2 to 2.3. They added this bundle to the composer.json. But it creates an error I don't understand :

Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-update-cmd event terminated with an exception

  [InvalidArgumentException]
  The dist file "app/config/parameters.yml.dist" does not exist. Check your dist-file config or create it.

What am I doing wrong?

keep-outdated should be keep-optional

I'm struggling a bit with the concept of keep-outdated. While it does perfectly what i need it to do, it does seem to describe the wrong concept for me.

In my .dist.yml file i actually ommit 2 parameters which are optional, since they have default values defined in the config file, however, if i do not keep them in the dist file, this script removes them.

So in this case, they are not outdated parameters as much as they are optional parameters, i think that would be better naming for it, or at least better motivation to keep those around, as outdated, the concept, means no longer used.

Just thought it worth the discussion.

Provide some sort of hint or explanation as to what parameters mean

It would be nice in my opinion if a parameter in the .dist file is prepended by a comment, that that comment would also be shown when asking for the parameters.

i.e.:

parameters:
    # A secret key that's used to generate certain security-related tokens
    secret:            test

would result in:

Some parameters are missing. Please provide them.
A secret key that's used to generate certain security-related tokens: secret (test):

It is sometimes hard to convey in a variable name what you want users to input upon install.

Invert the key/values in the env-map YAML array makes more sense

Hi,

The "env-map" array in the composer.json file expect to have a mapping between an environement variable (the key) and a key definition in the YAML parameters.yml file (the value).

ParameterHandler tries to parse the "env-map" with the YAML component to get a PHP array as a mapping.
PHP arrays can't have same key twice, the second affectation replace the previous value associated with the key used the first time.

As a consequence, you can't use the same env var several times for different mapping in the env-map array.

Ex: In my parameters.yml.dist file, I have the following database user declaration : 'database_user' and 'dev_database_user'.
Suppose we want to reuse the same env var to fill this two fields. We wanna to have a mapping array like this :

{
    "extra": {
        "incenteev-parameters": {
            "env-map": {
                "MY_DATABASE_USER": "database_user",
                "MY_DATABASE_USER": "dev_database_user"
            }
        }
    }
}

But the ParameterHandler script will only autofill the dev_database_user field, and will prompt the user for the desired value for database_user.

Whould it be make more sense to invert the key and values to allow multiple utilisation of an environement variable?

Ex:

{
    "extra": {
        "incenteev-parameters": {
            "env-map": {
                "database_user" : "MY_DATABASE_USER",
                "dev_database_user" : "MY_DATABASE_USER"
            }
        }
    }
}

I know that this change will cause every project to change their composer.json file. But I think that's a good improvement.

Import resources for more configs before comparison

We use several parameters_*.yml files based on environment and load a single parameters_base.yml file to avoid duplication of config settings. It seems ParameterHandler doesn't import this .yml file before comparison. Thus, it thinks there are settings that are needed, when they are actually set by the included file via the imports method.

Our parameters.yml:

imports:
    - resource: parameters_base.yml

Could the imports/resources be parsed for additional config settings before the comparison?

Copy parameters file based on ENV

It would be great if you could extract a parameters file based on your current env. The use case is as follows:

  • EnvA has parameter X=1, stored in parameters_envA.yml.dist
  • EnvB has parameter X=2, stored in parameters_envB.yml.dist

You don't necessarily want to merge both param files, as provided by #21, as you'll end up clobbering one setting or the other. If there were some way to examine the current env and add that as an optional prefix/suffix to the extraction, that would be pretty awesome.

"imports" section on the parameters.yml file

First things first, great work guys.

My issue is that I believe that when there is an "imports" section on the parameters.yml file, it should be kept untouched, however, it is removed.

eg.

imports:
    - { resource: more_third_party_parameters.yml }

parameters:
    database_driver: pdo_mysql
    ...

becomes

# This file is auto-generated during the composer install
parameters:
    database_driver: pdo_mysql
    ...

Please correct me if I am wrong

Option to throw exception on missing parameters in non-interactive mode?

Would it be possible to add an option so that, in non-interactive mode when a parameter is missing, an exception is thrown rather than the default copied from the .dist file?

Use-case: The parameter handler is great for our developers when they are working. But our deployments are automated. Usually the defaults given in .dist are not suitable for CI, QA or production environments. I want our build process to fail when keys are missing from our parameters file, and not copy the defaults.

Throwing exception in --no-interaction mode when some params are missing

In my build process i am using composer install --no-interaction command to set up the application.
Every application has composer.json file that contains
Incenteev\\ParameterHandler\\ScriptHandler::buildParameters handler set for
post-install-cmd event.

The problem is that if parameters.yml file has some parameters missing ParameterHandler automatically provides default values for them. It's ok for development but not for stage level.
In my case it would be cool if i can tell ParameterHandler somehow to throw an exception in --no-interaction mode if parameters file is not valid in order to explicitly abort the build/deploy of the potentially inconsistent application.

May be it would be reasonable to have some option / environment variable for this use case?

Handle multiple .dist Files

Hi there,

it would be really great to be able to specify an array of dist files which could be copied on rollout.

Especially if you work in a multi-environment in conjunction with the symfony2 environments. Therefore you could deploy all parameter_env.yml.dist to the config path of SF2.

You then could also use this Script to deploy other optional configuration .dist's

Ignore some parameters

I have a parameters.yml file with almost 60 parameters.

Most of them are rarely aim to be changed.

I would like to tell parameter-handler to ignore it on interactive asking and just take the default from dist.

Something like this:

{
    "extra": {
        "incenteev-parameters": {
            "ignored-keys": [
                "my_first_param",
                "my_second_param"
            ]
        }
    }
}

What do you think?

Can't use array for generating output parameters file with map-env

Hello,
I have settings from parameters.yml.dist mapped like this:
...

"incenteev-parameters": {
            "file": "app/config/parameters.yml",

            "env-map": {
                "database_driver":                  "DATABASE_DRIVER",
                 ......
                "pawq_param":                       "PAWQ_PARAM"
            }
        },

Now when during generation of parameters.yml I use

$ export PAWQ_PARAM=testvalue
 composer install --optimize-autoloader --no-progress --no-interaction;cat app/config/parameters.yml
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating optimized autoload files
> Incenteev\ParameterHandler\ScriptHandler::buildParameters
Creating the "app/config/parameters.yml" file
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
Clearing the cache for the dev environment with debug true
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets
Trying to install assets as symbolic links.
Installing assets for Symfony\Bundle\FrameworkBundle into web/bundles/framework
The assets were installed using symbolic links.
Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution
The assets were installed using symbolic links.
Installing assets for Nelmio\ApiDocBundle into web/bundles/nelmioapidoc
The assets were installed using symbolic links.
> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installRequirementsFile

# This file is auto-generated during the composer install
parameters:
.....
pawq_param: testvalue
....

but it does not work with arrays (default value from parameters.yml.dist is used):

$ export PAWQ_PARAM=("testval1", "testval2")
$ export | grep PAWQ
declare -ax PAWQ_PARAM='([0]="testval1," [1]="testval2")'
$ composer install --optimize-autoloader --no-progress --no-interaction;cat app/config/parameters.yml
......
# This file is auto-generated during the composer install
parameters:
.....
    pawq_param:
        - val1
        - val2

The output in parameters.yml should be:

 pawq_param:
       - testval1
       - testval2

Add multiple parameter-key support

Hi,
It would be useful to support a yaml file without a unique parameter-key or support when there is multiple parameter-key to check in one yaml file

ParameterHandler is adding unnecessary quotes to yaml values making it useless

Greetings,

I'm using Phalcon PHP, and decided to use the composer-parameter-handler to update application dist files.

The point is, I'm adding speciffically an exclamation point, since this is what the Phalcon Yaml Reader requires me to do, and for some odd reason, yours paramerter handler keeps adding this unwanted quotes.

Here is how to reproduce the error:

1 - Create a dist file, and add:
database_path: !app_path /db.sqlite
2 - Do a composer install
3 - Here is the result:
database_path: '!app_path /db.sqlite'

Unfortunatelly the YAML reader can't handle the app_path variable that should be replaced and everything goes to waste.

Any ideas?

Add build times as parameters

Post install time and post update time (UTC) to parameters.
For example,

#parameters.yml
post_install_time: 1321313
post_update_time: 1335456

Those parameters could be used for javascript

script.js?time=2132313

Or memcache namespace.

Import parameters from other subsections as well

If the parameters.yml-dist file has following structure:

parameters:
   login_required: false

twig:
    globals:
        show_forkme: true

Only the parameters section will be checked for missing parameters and imported, but the other sections remain unchecked / unimported. Should also import these.

[RFC] Be able to run only parameterHandler

Hello.

I would be nice to run only this composer hook.
I don't know how to do that.

Our deploy process look like this:

  1. composer install
  2. compute a code revision with a SF command: export PHAR_FILENAME=$(./app/console insight:phar:filename --env=prod)
  3. run composer run-script to re-use your lib SYMFONY_ENV=prod php /opt/composer.phar run-script post-install-cmd --no-interaction
  4. again step 2 and 3, but with different var
  5. A least, warm cache

So, I can, if you accept, to made the Composer\IO a soft dependency of the Processor class

provide handler scripts for setting scripts and extra default lines if missing

now we need to create LogSafe/ParameterHandler/Handler/Script.php to handle the insertion of

    "scripts": {
        "post-install-cmd": [
            "LogSafe\\ParameterHandler\\ScriptHandler::buildParameters"
        ],
        "post-update-cmd": [
            "LogSafe\\ParameterHandler\\ScriptHandler::buildParameters"
        ]
    },
    "extra": {
        "logsafe-parameters": {
            "file": "app/config/parameters.yml"
        }
    }

check if it is a symfony2 project, check that it has them and if not then insert the lines above.

For parameters through env vars that should be handled by the user.

support for behat i guess yaml component does not support it

@stof this does not work for behat right? ๐Ÿ‘ถ

default:
    extensions:
        'Behat\MinkExtension\Extension':
            base_url: 'http://demo.sonata-project.org/'
            goutte:    ~
        "incenteev-parameters": [
            {
                "file": "app/config/parameters.yml",
                "dist-file": "app/config/parameters.yml.sample",
                "keep-outdated": true
            },
            {
                "file": "behat.yml",
                "dist-file": "behat.yml.dist",
                "parameter-key": "default",
                "keep-outdated": true
            }
        ]
generating autoload files
Updating the "app/config/parameters.yml" file
Updating the "behat.yml" file
PHP Fatal error:  Class 'Sonata\BasketBundle\SonataBasketBundle' not found in /Users/cordoval/Sites/libs/sandbox/app/AppKernel.php on line 58
PHP Stack trace:
PHP   1. {main}() /Users/cordoval/Sites/libs/sandbox/app/console:0
PHP   2. Symfony\Component\Console\Application->run() /Users/cordoval/Sites/libs/sandbox/app/console:16
PHP   3. Symfony\Bundle\FrameworkBundle\Console\Application->doRun() /Users/cordoval/Sites/libs/sandbox/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:121
PHP   4. Symfony\Component\HttpKernel\Kernel->boot() /Users/cordoval/Sites/libs/sandbox/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:70
PHP   5. Symfony\Component\HttpKernel\Kernel->initializeBundles() /Users/cordoval/Sites/libs/sandbox/app/bootstrap.php.cache:2214
PHP   6. AppKernel->registerBundles() /Users/cordoval

setting current timestamp on run

I've got a parameter in my parameters.yml that needs to be updated on each deployment to a current timestamp. Or more specifically, to a completely different value that was not used before.

This value is used as a suffix for the assets-url's, to make sure clients pick up the new versions after a deployment, instead of getting stuck with an old version.
A timestamp has worked perfectly for me for this case.

It would be nice if this value is auto-updated.

I would suggest adding an additional optional parameter called update-timestamp, which should be a string for the parameter-name that must be set to the current timestamp.

I can create a pullrequest for this, it should not be a big change.
I'm just polling first to see if this request will be accepted or not.

Adding support for variable parameters

In Symfony2, it's possible to define this:

framework:
    templating:
        engines: ['twig']
        assets_version: %assets_version%

And it could be great to be able to define in the dist file something like that:

parameters:
    assets_version: {{ date().timestamp }}

This could be very useful for cache busting on deployment

keep-optional default true or ask user about removal.

The behaviour now is that parameters in .yml are silently removed if they are not in yml.dist.

I propose that either keep-optional is default true, so this will not happen, or better, ask the user if it's supposed to be removed or not.

I just did a quick upgrade form sf 2.5.0 beta 2 to release on my dev instance, which was in the middle of a change possibly needing a new parameter. That just went without a puff of smoke. And since parameters.yml shall not be in CVS (git), I have to recreate the new parameters.

I've added keep-optional now, but this was behaviour that was "silently" added in some update of Symfony, which pulled this package, with this new behaviour. I qould guess that more developers than me will be surprised by this :=)

preserve syntax of parameters

repositories: { symfony: { include: [symfony, symfony-docs, symfony-marketing, symfony-standar] } }

before it was a nice nested thing

Support of multiple kernels

We are having something like multiple kernels: actually kernel only one, but it loads specific parameters.yml for different hostnames and store cache/logs in separate folders for hostnames.

How it possible use ParameterHandler for this case?

Override parameter.yml.dist values from Environment Variables

Currently, Symfony supports setting parameters from environment variables where they are of the form SYMFONY__* but it later overwrites any of these parameters using the values it reads from parameters.yml. Whilst it is arguable that Symfony ought to assign higher precedence to the environment variables, should ParameterHandler perhaps be using the same Environment Variables above the values in parameters.yml.dist when generating parameters.yml?

create new tag 2.0.1 or 2.1.0

Please create a new tag 2.0.1 or 2.1.0 to be able to use cached versions with composer and also to use new features like #21 .
(Because #21 is only included in master right now)

Support for .env besides parameters.yaml?

If migrating to Docker, a proper way to enable app container configuration is via environment variables.

This means my Symfony 3.2+ parameters.yml looks like

parameters:
    database_host: '%env(DATABASE_HOST)%'
    database_port: '%env(DATABASE_PORT)%'
    database_name: '%env(DATABASE_NAME)%'
    database_user: '%env(DATABASE_USER)%'
    database_password: '%env(DATABASE_PASSWORD)%'

(meaning I'll probably be able to move it to config.yml and remove parameters.yaml* altogether) but I still do need to create a .env in project root to configure those vars for docker-compose usage.

With Symfony 3.3 getting dot-env component and support, is there a way for adding support for .env (from .env.dist or similar)? It's basically the same thing as existing, only the input/output file is serialized differently.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.