enviroment configuration

[iannsp]

I need use the same ini file to configure properties for different enviroments like Development, Staging, Live and so on. Its normally implemented using sections name and repeating the properties into those sections. I have(or dont find) no way to do this because sections are used to define scope for objects configuration.

[henriquemoody]

I have suggested to @augustohp and @alganet some reserved words starting with @. Something like

foo = 123
bar = 456
; With checking
@include[] = '/path/to/file.ini'
; Without checking
@-include[] = '/path/to/file.ini'

Thinking that this should overwrite the current variables with its values, it will solve part of the problem.

[iannsp]

I dont like... sound as an metadata, I know. something like annotations in text file ;)

[alganet]

These environment settings are just a way to extend and mix containers. You have two or more containers and some of them can reuse and replace entries from one another.

This is actually possible with the current implementation. Something like:

MyProject
  \ - src
  | - test
  | - conf
    \ - production.ini
    | - development.ini
    | - jenkins.ini
    | - application.ini
    | - database.ini
    | - router.ini
  | - docs

So, the production.ini, development.ini and jenkins.ini files are configurations for environments. The database.ini and router.ini are application-specific. The application.ini file is an abstract container.

application.ini

posts_per_page = 30
lists_enabled = true
; ...

database.ini

[conn PDO]
dsn = [db_dsn]
user = [db_user]
pass = [db_pass]
[mapper Respect\Relational\Mapper]
db = [conn]
; ...

router.ini

[router Respect\Rest\Router]
; ...

production.ini

db_dsn = "mysql:host=my-production-host;dbname=my-production-db"
db_user = "myproduser"
db_pass = "myprodpass"

development.ini

db_dsn = "mysql:host=localhost;dbname=mydb"
db_user = null
db_pass = null

jenkins.ini

db_dsn = "sqlite::memory:"
db_user = null
db_pass = null

To use and mix those guys, you call:

$c = new Container();
$c->loadFile("conf/application.ini");
$c->loadFile("conf/router.ini");
$c->loadFile("conf/database.ini");
$c->loadFile("conf/production.ini"); //change this to change env

Also, I've been using a recursive container manifest like this on my own projects:

manifest.ini

[container Respect\Config\Container]
loadFile[] = "conf/application.ini"
loadFile[] = "conf/router.ini"
loadFile[] = "conf/database.ini"
loadFile[] = "conf/" ENVIRONMENT ".ini" ;Respect\Config can use constants.

And using it like:

define('ENVIRONMENT', getenv('MY_ENV_FROM_APACHE_CONF'));
$c = new Container('conf/manifest.ini');
$c = $c->container; //switch the meta-container for the real one.

I believe this is enough and the syntax doesn't look hacky. It's way more extensible than hacking the ini format to allow our own syntax sugar, but I'd like to hear your opinion. What do you think?

[iannsp]

is a good pratice use differente files for different enviroments but some developers use all envs in a same file to avoid missing change something or avoid missing add something. Well, as a Vi User(hehe) I can see more then one file in the same without change the tab but can work with a single file is important because the happypanda moments when u incurs in erros by missing

[henriquemoody]

(Out)

Respect logo should be a Panda with a magic cube in the hands. (the idea of the cube was of @iannsp).

\o/

[iannsp]

something like this http://www.flickr.com/photos/gabique/4849646010/, but strong instead of cute ;)

[henriquemoody]

This panda do not appears to be "respectable", got it? LOL

[nickl-]

@henriquemoody This is ambiguous:

<?php

@include[] = '/path/to/file.ini'
; Without checking
@-include[] = '/path/to/file.ini'

They are not includes, agree? @alganet is on the right track with loadfile or you may consider import ala less/sass/css but don't confuse this with include and require.

[iannsp]

besides I understand all point u guys show up here I still insist in the fact of having(or can have) all environments setting up in a single file. Its because its easily maintainable, reduce the error by missing probability and, in the end, isn't a bad pratice on ant-pattern. Instead of it, is a common pratice.

I suggest someting like this as possible option: [ENVIRONMENT DEV] db_user = 'devuser' [ENVIRONMENT LIVE] db_user = 'liveuser'

If we establish some terms as reserved, defining ENVIROMENT as one of those, and make the necessary to support this exacly we support namespace(for example), I believe "YES, WE CAN"(sorry republicans, my bad) thats is my 2 cents

[augustohp]

That's is good discussion!

@iannsp idea is valid and I agree that we already have support for this environment-aware container (better than any other implementation I've seen), BUT @iannsp may have some kind of problem with the actual solution. If this is the case, presenting this problem would be probably something to happen next.

Apart from that, let me notice that if we support the "ENVIRONMENT" reserved word (and implementation) I am afraid we will be soon facing the need of a "extension of enviroments" just like Zend Framework does. Needless to say that it is something we will probably regret later on (see ZF2 issues on that).

Just in note, Symfony does something different. It has different files for each environment.

• app.php for production
• app_dev.php for development

[alganet]

Not tested, but I believe this is possible:

[development]
user = alganet

[production]
user = respect

account = [user]

Using:

const ENVIRONMENT = 'production';
$config  = parse_ini_file('config.ini');
$config += $config[ENVIRONMENT];
$container = new Container($config);
print $container->account; //respect

[nickl-]

[nickl-]

completed EnviromentConfigurationTest

[alganet]

Yay awesome :panda_face:

[augustohp]

@nickl- You are awesome!

[henriquemoody]

:panda_face: