hassankhan / config Goto Github PK

Not sure if you'd want this in the library, but we could implement the ArrayAccess interface to allow for array-style get-set operations. The following would both be the same thing:

$config->get('key');
$config['key'];

• Add a ConfigInterface
• Break file loaders into separate classes, implementing ConfigLoader interface
• Check MIME type of file rather than extension
• Add a simple(r) way of defining default options
• Add a proxy class (shameless self-plug)
• Add Scrutinizer
• Add extension aliases
• Get some nice documentation in
• HHVM support

Just creating this issue based on PR 43 😄

I'm not sure what the benefit is to being able to return a callable when including the PHP config. We would be able to do any logic within the file before returning an array.

Personally the only time I can see this being valid is if we was going to pass a param in when invoking.

Obviously changing this would break BC so not a major issue with keeping it in, was just wondering what the use case would be.

It seems that the Config class is missing an array_merge() like the AbstractConfig does.

Right now if I add a default configuration, it will get ignore since $this->data is not merge with the getDefaults() method.

Deprecated: The ability to pass file names to the Symfony\Component\Yaml\Yaml::parse method is deprecated since version 2.2 and will be removed in 3.0. Pass the YAML contents of the file instead

Recommend just adding a file_get_contents for the file and feed the returned text into the method.

Please check here https://github.com/hassankhan/config/blob/master/src/Config.php#L76
It's the "Noodlehaus\FileParser\FileParserInterface" instead of the "Noodlehaus\File\FileInterface", right?

Please add a Sava to the file method

Hey,
I'm a Node.js developer which needs to program an app using PHP for college! So I thought of using this config manager, which is very alike with node-config.

But I want to override a few options with environment variables, because of Heroku, for example. node-config allows me to do this via an special custom-environment-variables configuration.

What do you think of implementing something similar in your amazing project?

$c = new Config('config.default.json', '?config.json');

If config.json isn't found, it won't throw an error.

cache values for paths so get()/set() don't have to traverse the path everytime.

calling set($key, $value) with value set to null does not remove or unset that config setting.

Demo Code

$this->config->set('database', array(
    'host' => 'localhost',
    'name' => 'mydatabase'
 ));

$this->config->set('database.host', '127.0.0.1');
$this->config->get('database'); //cache 

$this->config->set('database.port', 3306);
$this->config->get('database'); //cache

Reset cache data when use the function set?
Recursive cache list and match it?
Feeling is a daunting job.

Hi,
good library. What do you think to create an official release so we can point to a specific one in our composer.json?

Thanks and Regards

hides

I know we've talked about this before, and I know we decided it went against the spirit of the project etc. BUT I think it may be time. 👍

I have a use-case where I load a JSON representation of an access token from my Config, instantiate as an AccessToken and put it back. In my getDefaults(), I specify null for the access_token.

If no access token is provided, I'd prefer the access_token weren't available, but guess what? $config ->has('access_token') returns true - which isn't unexpected behaviour, this is what we wanted.

One way of fixing it is to run array_filter() over the defaults in the subclass ... or should we move that to the AbstractConfig?

Another would be to add the remove() method which would actually remove the key. 😄

I realise now that I'm describing two different issues here, apologies for the ramble.

I really like your library. I wanted to have a default Config object, and I thought it'd be easier to extend the Noodlehaus\Config object and then set $this->data to my data.

Unfortunately, I can't currently do this because $this->data is a private attribute. Do you think I could make a PR and change this?

It'd be nice to have

PHPUnit 5.3.4 by Sebastian Bergmann and contributors.

Runtime: PHP 5.6.20-0+deb8u1
Configuration: /home/onedal/devel/onedal/config/phpunit.xml.dist
Error: No code coverage driver is available

...............................................F................ 64 / 64 (100%)

Time: 121 ms, Memory: 12.25Mb

There was 1 failure:

1. Noodlehaus\FileParser\Test\JsonTest::testLoadInvalidJson
   Failed asserting that exception message 'quoted object property name expected' contains 'Syntax error'.

FAILURES!
Tests: 64, Assertions: 127, Failures: 1.

Hey and thanks for the library,

a nice addition could be to allow validation of the config against a defined schema file (for example via https://github.com/justinrainbow/json-schema).

Would you be interested in a pull request in that area?

Susi

Hi, so this just bit me: #41

Could you please tag a new release so Composer starts seeing this change?

Thank you.

As of 3.0 symfony/yaml's Yaml::parse() doesn't accept a file path any more, thus is currently unusable.

Happened to me and it did not throw an exception, as symfony/yaml happily parsed the file path apparently.

I can't seem to update value in a file, what am I doing wrong?

<?php

use Noodlehaus\Config as Config;

$config = Config::load($app->config('base_path') . '/config/config.yaml');
$next_number = $config->get('accounting.next_number');
$new_number = ++$next_number;
$config->set('accounting.next_number', $new_number);

I can return the get value so the file is readable etc. But it wont update the value in the file.

A new public method getSupportedFileExtensions that returns the collected extensions of all parsers.

This would make it easier to scan directories only for supported file types.

Edit: If that's too specific, a getSupportedFileParsers would be fine too :)

I'm happy to implement either, just looking for feedback first.

For cases where null is actually a value, shouldn't we just set it as that.

If a value must be removed, we can add another method. Only reason being, and I'm pretty sure a test case would show this, is that in JSON, null is a valid value.

Currently one test is failing (something about INI files). It's probably worth the effort to fix it, just cos 😉

Can you add XML to the list of supported format in the description?

Thanks.

Hi!

From the README file it was not clear if it supported lazy loading.
Can I set the folder where all my config files are stored and include only those which were requested on runtime?

I don't know, Noodlehaus seems to be a really lousy namespace for this, and makes it a bit hard to take the package seriously.

I see you need to explicitly name your files .yaml and not .yml for this to work.

But a lot of frameworks, like Symfony use .yml for some reason.

Maybe add support so it works with both?

Was this discussed before? i couldn't find an issue about it.

Loading an XML from string will be beneficial since sometimes we don't have a file saved on the file system to load.

Personally I was thinking using this repo to get it going, thoughts?

running unit tests for my project which uses Noodlehaus\Config, i was presented with this error while attempting to parse an .ini file that contained no parsable content.

TypeError: Argument 1 passed to Noodlehaus\Exception\ParseException::__construct() must be of the type array, null given

this ocurred in php 7.0.8 with the content of the test .ini file being 'no parsable content'.

investigating showed the issue appears to happen because parse_ini_file() returns null if there is no ini-style syntax in the target file, but does not set an error, leaving error_get_last() to return NULL which, being a non-array, causes ParseException to fail when thown.

i have a pr with the fix for your consideration. apologies in advance if my pr submission procedure isn't perfect; i live in a bitbucket/mercurial bubble and confess i struggle somewhat with git.

love the project!

If possible.

Config::load([
     'app.php',
     'database.php'
]);

// or load config folder
Config::load(__DIR__ . '/config');

// database.php
<?php
return [
       'default' => 'mysql', 
       'test' => [
             'nested' => 'one'
       ]
];

//Accessing
Config::get('database.default'); // returns mysql
Config::get('database.test.nested'); // returns one

If possible and you have enough time.

Thanks in advance. Kim of Cebu/Singapore ^_^

After you changed the namespace I uninstalled the old one and installed this I am getting an error in my logs:

[:error] [pid 15040] [client 127.0.0.1:59912] PHP Fatal error: Class 'Symfony\Component\Yaml\Yaml' not found in /home/httpd/myapp/vendor/hassankhan/config/src/FileParser/Yaml.php on line 29

So I installed it with:

composer require symfony/yaml ~2.5

But I still get the same error.

What else am I missing?

With the README.md update and all, shall we?

Did I overlook something or is there support for using tokens with replace like Symfony does in config files.

For example you have a config file:

config.yml:

database:
    host: %hostname%
    user: %username%
    password: %password%

Then you have a file for example parameters.yml

parameters.yml:

database:
    host: example.com
    user: example
    password: password

Then you only need to replace the parameters.yml on each environment and keep one config file complete. Instead of having multiple config files you need to edit if you add or remove values.

When constructing a new Config object, if the target file is empty, the following two warnings are emitted:

Warning: array_replace_recursive(): Argument #2 is not an array in src/Config.php on line 65
Warning: array_merge(): Argument #2 src/AbstractConfig.php on line 39

$this->data = array_replace_recursive($this->data, $parser->parse($path));

This is due to the fact that the Yaml parser will return null if the file is empty (thus not an array). An "easy" fix would be to cast the result of $parser->parse($path) to an array:

$this->data = array_replace_recursive($this->data, (array)$parser->parse($path));

What do you think?

Not everyone is going to use YAML for configuration. symfony/yaml should be an optional dependency.

how to get an item, for example, where key = 1

{
  "items":[
    {
      "key":"0",
    },
    {
      "key":"1"
    }
  ]
}

Does this support caching?

I use YAML files extensively but parsing the YAML files on every request becomes costly.

Symfony for example caches the YAML config files so it would be nice if this could do it as well rather than building my own cache solution.

array(
    'env1' => [
        'servers' => array(
            'host1',
            'host2',
            'host3'
        ),
    ],
    'env2' => [
        'servers' => array(
            'host4',
            'host5',
            'host6'
        ),
    ],
    'env3' => [
        'servers' => array(
            'host7',
            'host8',
            'host9'
        ),
    ],
);

$servers = Config::has('*.servers');

The example is contrived, but I've needed something similar in a project already. Not quite sure how we're gonna figure it out though 😕

Fatal error: Uncaught exception 'Noodlehaus\Exception\FileNotFoundException' with message ' in C:\wamp64\www\autentication\vendor\hassankhan\config\src\Config.php on line 153

this is was my code:

<?php
use Slim\Slim;
use Noodlehaus\Config;
session_cache_limiter(false);
session_start();

ini_set('display_errors', 'on');

define('INC_ROOT', dirname(__DIR__));

require INC_ROOT .'/vendor/autoload.php';
require_once INC_ROOT . '/vendor/hassankhan/config/src/Config.php';

$app = new Slim([
	'mode' => file_get_contents(INC_ROOT . '/mode.php')
]);
echo $app->config('mode');
$app->configureMode($app->config('mode'), function() use ($app) {
	$app->config = Config::load(INC_ROOT . "/app/config/{$app->mode}.php");
});


?>

Regarding an old issue #18:

It was asked how to handle when multiple config files share a variable name.

If you're loading in multiple config files, wouldn't it make more sense to contain each loaded file as its own array within the config container?

loading files:
- config/environment.php
- config/services.php
- config/database.php

These should be accessible in the following way:

$app->config = new Config(__DIR__ . '/../config');
$app->config->get('environment.name'); // the name variable is returned from the environment config
$app->config->get('database.server'); // the server variable is returned from the database config

Currently, all the config options are mashed together in a single array, which overwrites any duplicates.

Example:
server.php

<?php

return [
    "system" => "debian",
    "apache" => [
        "location" => "/usr/bin/apache"
    ]
];

environments.php

<?php

return [
    "local" => [
        "domain" => "dev"
    ],
    "production" => [
        "domain" => "domain.com"
    ]
];

Outputs:

{
    "local":{
        "domain":"dev"
    },
    "production":{
        "domain":"domain.com"
    },
    "system":"debian",
    "apache":{
        "location":"\/usr\/bin\/apache"
    }
}

However, I would like it to output:

{
    "environments":{
        "local":{
            "domain":"dev"
        },
        "production":{
            "domain":"domain.com"
        },
    },
    "server": {
        "system":"debian",
        "apache":{
            "location":"\/usr\/bin\/apache"
        }
    }
}

PHP 5.3 is ... outdated to say the least.

Since the library is fairly mature, I think maybe we should do any last tidy ups, then do a 1.0 release with 5.5.9 set. That way, anyone still using older versions can use <1.0 and still be fine (I think)

I'm wondering if you'd consider adding support for merging duplicate keys in a config file. My use case for this is wanting to have multiple environment config sections in a file since it makes config easier to organize by functionality. Example:

# Messaging config
dev:
  msg-host: foo

prod:
  msg-host: bar

# Database config
dev:
  db-host: foo

prod:
  db-host: bar

Ideally, this would be merged when loaded to:

dev:
  msg-host: foo
  db-host: foo

prod:
  msg-host: bar
  db-host: bar

While I could just write my config fully merged by environment, with a lot of config and multiple environments it's easier to maintain when it's organized by functionality.

Should have probably incremented as we ticked off items from #26. Opinions on skipping a few minor versions and going to 0.9?

something like $conf->getAll() and return an array - I need that atm for debugging

I have installed via composer and am including the autoloader but I'm getting the following error:

Class 'Config' not found

autoload_psr4.php contains:

// autoload_psr4.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Noodlehaus\\' => array($vendorDir . '/hassankhan/config/src'),
);```

and is being loaded by ```autoload_real.php```

Hi, I was wondering if src/Config.php#L55 was an oversight? It makes inheriting the previous config more difficult that it should be:

class Config extends \Noodlehaus\Config
{
    protected function getDefaults()
    {
        static $buffer = array();
        $data = $buffer;

        $buffer = array_replace_recursive($buffer, $this->data);

        return $data;
    }
}

The only other thing I can think of is re-implementing the entire Noodlehaus\Config class.

For example:

/**
 * Get all of the configuration items
 *
 * @return array
 */
public function all()
{
    return $this->data;
}

$config = \Noodlehaus\Config::load($path)->all();

foreach ($_POST['config'] as $k => $v)
{
    $config[$k] = $v;
}

// do something blah, blah, blah

$data = '<?php return ' . var_export($config, true) . ';';

if (false !== file_put_contents($source, $data))
{
    @copy($source, $target);
    @chmod($target, 0777 & ~umask());
    @unlink($source);
}

Similar to issue #16. Syntax here: http://ne-on.org/
It's made by/for Nette framework.
These both issues would make this package usable for almost every framework.

I'd be for standalone repositories with suggestion in composer:

• noddlehaus/config-yaml
• noddlehaus/config-neon

I can send PR for this support.