(SS3) Config layer

[Hamish Friedlander]

Hi All,

Part of the work we're looking to do for SilverStripe 3 is to add a static configuration layer. This will become the preferred configuration system, although _config.php will remain both to support legacy code & because some configuration needs to be set dynamically. This has several advantages, mostly around performance:

- Classes won't get auto-included (and won't auto-include their dependancies) just to set configuration

- The resulting configuration can be cached, reducing start up time

- Configuration fragments can be provided at different priorities and for different environments, making it easier for modules to provide defaults per environment (live, dev, etc) and override other modules defaults

=== Setting configuration variables ===

I've worked up a demonstration of how I think the configuration could look and put it on github at https://github.com/hafriedlander/silverstripe-config-experiment. This isn't (yet) a working example, just a demo to show how I think configuration could be structured.

The key points are:

- In addition to _config.php there is also an optional directory, _config, with various configuration fragments in it

- These fragments are in a superset of YAML (more on that in a minute)

- Each fragment should start with a number, and each fragment will be included from lowest to highest, regardless of the module it's in. So it the demo, sapphire/_config/001-routes.yml is first, then sapphire/_config/010-routes.yml, then cms/_config/050-routes.yml, then the other sapphire/_config fragments.

The format of the config fragments is mostly YAML, but with a few extensions:

- Values can start with a = (see mysite/_config/200-couchdb.yml) to specify PHP values, or =& (see mysite/_config/500-project.yml) to specify references to other config values

- Ordered lists normally add more items to any existing items in the list. Values can start with a ! to mean "remove this item from the list if it exists" (see subsites/_config/101-reports.yml). Potentially there'd be a syntax to say where in the list to add items (see cms/_config/100-cms-editor-config.yml).

=== Using configuration values ===

As far as how these configuration values are made available to the system, I haven't entirely decided how that should look yet. 

We currently have a bunch of different ways of storing configuration (static properties, static setter methods, singleton properties, singleton setter methods, constructor arguments to items that are then set to static properties, etc). We could make the static configuration system auto-guess where to store different values, or have some metadata specification on where to store config values. The other option is to provide a new API and require code be upgraded in order to use this new system. I tend to favour the later, as it's a little cleaner.

As far as the new API goes, I'd probably suggest two interfaces

(1) Directly access the configuration API

class Configuration {

  static function get($str);

  // This would also be where the config parsing / caching layer lives

}

This would be called with a dot separated string, like Configuration::get("Director.Routes");

(2) Built into the Object class

class Object {

  function getConfig($str);

}

Like Configuration::get this would be called with a dot-seperated string, but that string would automatically be prepended with the class name, like

class Director {

  function arbitraryExampleMethod(){ $this->getConfig("Routes"); }

}

We might instead use Dependancy Injection (email on that coming) to inject an object into Objects that uses __get to expose configuration values, like:

class Director {

  /** @inject(ConfigurationInterface) */

  protected $config

  function arbitraryExampleMethod(){ $this->config->Routes; }

}

But we can't do that for the global Configuration object, since there's no __getStatic, so Configuration::Director::$Routes wouldnt be possible.

Thoughts? Anybody have any alternate format ideas or preferences? Any examples of current _config.php code that (a) isn't dynamic and (b) would be awkward to describe in this suggested format?

Hamish Friedlander

SilverStripe

[Sean Harvey]

We already have a SiteConfig class for managing some of the site
configuration, have you considered integrating that into the same
configuration scheme you're proposing here?

On Mar 17, 3:07 pm, Hamish Friedlander <ham...@silverstripe.com>
wrote:

> Hi All,
>
> Part of the work we're looking to do for SilverStripe 3 is to add a static
> configuration layer. This will become the preferred configuration system,
> although _config.php will remain both to support legacy code & because some
> configuration needs to be set dynamically. This has several advantages,
> mostly around performance:
>
> - Classes won't get auto-included (and won't auto-include their
> dependancies) just to set configuration
>
> - The resulting configuration can be cached, reducing start up time
>
> - Configuration fragments can be provided at different priorities and for
> different environments, making it easier for modules to provide defaults per
> environment (live, dev, etc) and override other modules defaults
>
> === Setting configuration variables ===
>
> I've worked up a demonstration of how I think the configuration could look

> and put it on github athttps://github.com/hafriedlander/silverstripe-config-experiment. This isn't

[Hamish Friedlander]

SiteConfig is database-stored user-level configuration.

This new system extends _config.php, is stored as code and is developer-level configuration.

This might be a false dichotomy. However I'm generally against pushing configuration into the database - it means it can't be Version Controlled, can't easily be transferred between environments, can't be propagated during an update without nasty database merges

SiteConfig also isn't nested - it's the configuration of the "Website", but not all of the configuration for the system.

On the other hand, there's no reason that what's currently in SiteConfig can't be treated as just a layer on top of _config, so that you could do

500-site.yml

Site:

  Title: "My Site"

  Tag: "It's awesome"

And then have that overriden (or maybe have it override) what's stored in the SiteConfig object in the database.

Hamish Friedlander

SilverStripe

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Will Rossiter]

- Each fragment should start with a number, and each fragment will be included from lowest to highest, regardless of the module it's in. So it the demo, sapphire/_config/001-routes.yml is first, then sapphire/_config/010-routes.yml, then cms/_config/050-routes.yml, then the other sapphire/_config fragments.

I don't like the look of numbers attached to configuration files. Could a better way perhaps be to select configuration from sapphire, then modules, then project code. Modules could be included by a rough calculation from the module manager dependancies (subsites extends cms for instance)

Part of the work we're looking to do for SilverStripe 3 is to add a static configuration layer. This will become the preferred configuration system, although _config.php will remain both to support legacy code & because some configuration needs to be set dynamically. 

Just looking through the _config file I have open now I can quite a few things such as class_exists() calls which would have to stay dynamic? unless we have some layer in the YAML parser to handle this?

--
Will Rossiter | Developer
SilverStripe
http://www.silverstripe.com

Mobile: +64 27 389 3454
Office: +64 4 978 7330 ext 58
Skype: will.rossi

Level 5, 97-99 Courtenay Place
Wellington, New Zealand

[Hamish Friedlander]

Swapping the order of your comments :)

Part of the work we're looking to do for SilverStripe 3 is to add a static configuration layer. This will become the preferred configuration system, although _config.php will remain both to support legacy code & because some configuration needs to be set dynamically. 

Just looking through the _config file I have open now I can quite a few things such as class_exists() calls which would have to stay dynamic? unless we have some layer in the YAML parser to handle this?

I'd like to see your examples, but part of the reason I included the subsites module is to give an example of how I'd imagine dealing with this. In the original cms/_config.php we've got this:

if (class_exists('SubsiteReportWrapper')) SS_Report::register('ReportAdmin', 'SubsiteReportWrapper("BrokenLinksReport")',-20);

else SS_Report::register('ReportAdmin', 'BrokenLinksReport',-20);

This is horrible. It means that the Subsites module required changes to the core CMS to work, which is exactly the opposite of what we want.

The new system has:

cms/_config/100-reports.yml

SS_Report:

    Reports:

        - BrokenLinksAdmin

subsites/_config/101-reports.yml

SS_Report:

    Reports:

        - ! BrokenLinksReport

        - SubsiteReportWrapper("BrokenLinksReport")

Which seems cleaner. Not perfect (it assumes the cms module is installed, although since it's just static it won't error out if it's not so at least in this instance it's OK), but a lot better than the original.

On 17 March 2011 16:28, Will Rossiter <wi...@silverstripe.com> wrote:

- Each fragment should start with a number, and each fragment will be included from lowest to highest, regardless of the module it's in. So it the demo, sapphire/_config/001-routes.yml is first, then sapphire/_config/010-routes.yml, then cms/_config/050-routes.yml, then the other sapphire/_config fragments.

I don't like the look of numbers attached to configuration files. Could a better way perhaps be to select configuration from sapphire, then modules, then project code. Modules could be included by a rough calculation from the module manager dependancies (subsites extends cms for instance)

They're not super pretty, but neither is _config. I think explicit priority is better than implicit, and just "sort-of-alphabetically, all of one module at a time" which is what we've got now isn't good enough - the above example for instance wouldn't work if the subsites module was called "allsubsites" instead.

I like the idea of using the module dependancies, but they don't exist at the moment and may or may not make it into SS3.

Even then, I'm sure there's situations when I've been extending a module (A) with another module (B), and I've wanted to do _some_ of B's configuration before A's, and some after. Can't think of any off the top of my head now though.

It also replaces all the ad-hoc "priorities" we've got on some APIs now (cache, routing, etc).

 

Hamish Friedlander

SilverStripe

[Sean Harvey]

> I don't like the look of numbers attached to configuration files. Could a better way perhaps be to select configuration from sapphire, then modules, then project code. Modules could be included by a rough calculation from the module manager dependancies (subsites extends cms for instance)

I think having it automatically determine priority is too "magical",
and might make debugging harder for when configuration doesn't
overridden by a certain module or mysite code.

> Just looking through the _config file I have open now I can quite a few things such as class_exists() calls which would have to stay dynamic? unless we have some layer in the YAML parser to handle this?

class_exists() around configuration parameters seems to be hacking
around a problem with the loaded class manifest. Apart from that, the
only other times I've seen is people using conditional configuration
setting is checking Director::isLive(), however that indicates a lack
of environment configuration through _ss_environment.php.

[Sam Minnée]

On 17/03/2011, at 4:28 PM, Will Rossiter wrote:

>> - Each fragment should start with a number, and each fragment will be included from lowest to highest, regardless of the module it's in. So it the demo, sapphire/_config/001-routes.yml is first, then sapphire/_config/010-routes.yml, then cms/_config/050-routes.yml, then the other sapphire/_config fragments.
>
> I don't like the look of numbers attached to configuration files. Could a better way perhaps be to select configuration from sapphire, then modules, then project code. Modules could be included by a rough calculation from the module manager dependancies (subsites extends cms for instance)

It's nice to have fragments as an option, but it seems like the kind of thing that we should only have to use if we need to. Ideally for simple sites we can just have mysite/_config/mysite.yml or something.

>
>> Part of the work we're looking to do for SilverStripe 3 is to add a static configuration layer. This will become the preferred configuration system, although _config.php will remain both to support legacy code & because some configuration needs to be set dynamically.
>
> Just looking through the _config file I have open now I can quite a few things such as class_exists() calls which would have to stay dynamic? unless we have some layer in the YAML parser to handle this?

We're not going to rewrite PHP in YAML.

We'll need to enumerate the situations where the configuration is set to one of a number of things based on options, and provide support for those.

I'm guessing that your class_exists() thing is having configuration that varies depending on whether or not a module is installed, or when a specific version of that module is installed.

Some of the optional configs that I can see us needing to support:

- a class existing
- a module being installed
- environment type being dev, test, or live
- an environment flag being set

After writing this, Hamish had a nice solution where modules have updated report config which is cool.

[Sean Harvey]

> I'd like to see your examples, but part of the reason I included the
subsites module is to give an example of how I'd imagine dealing with
this.
In the original cms/_config.php we've got this:

Here's some other examples I've seen of conditional configuration:

// fallback for environment file lacking configuration
if(!defined('SS_API_HOST')) define('SS_API_HOST',
Director::absoluteBaseURL() . '/ui/web/htdocs');

if(class_exists('ControllerExtension')) {
Object::add_extension('Controller', 'ControllerExtension');
}

if(defined('SS_LOG_ENABLE')) {
SS_Log::add_writer(new EmailErrorWriter('mye...@mysite.com'));
}

[Sam Minnée]

> They're not super pretty, but neither is _config. I think explicit priority is better than implicit, and just "sort-of-alphabetically, all of one module at a time" which is what we've got now isn't good enough - the above example for instance wouldn't work if the subsites module was called "allsubsites" instead.

Do we want to remove the _ from _config? Is there a good reason to have it?

Do the numbers have to be at the beginning? It seems like the priorities have more do to with resolving priorities between modules than within on, which means that sorting the contents of subsites/_config/ by priority is of limited use.

Do we want to spell out some priority categories so that people know which numbers to pick as a starting point? That'll help avoid the z-index arms-
race that you get in CSS sometimes. ;-)

For example:

- 100: sapphire
- 200: core modules without dependencies on anything else beyond sapphire - e.g, cms
- 300: basic configuration by core cms modules that don't refer to others; manipulations of cms and/or sapphire configuration
- 500: changes by one module of the behaviour of another module.
- 700: changes from customised versions of modules that are designed for a small number of projects. for example, if a company has its own suite of modules their configuration manipulation would be at this level.
- 900: project-specific changes.

> I like the idea of using the module dependancies, but they don't exist at the moment and may or may not make it into SS3.

That's prudent, but let's leave the door open for it.

[Hamish Friedlander]

It's nice to have fragments as an option, but it seems like the kind of thing that we should only have to use if we need to.  Ideally for simple sites we can just have mysite/_config/mysite.yml  or something.

It'd be strictly alphabetical on fragment names (hence the 0 padding), so that'd work fine, it'd just come after the numbered fragments 

Some of the optional configs that I can see us needing to support:

 - a class existing
 - a module being installed
 - environment type being dev, test, or live

I imagined this might work by having subdirectories of _config, so

mysite/_config/dev/500-dev-database.yml

Do we want to remove the _ from _config?  Is there a good reason to have it?

Nah, I like it. Most directories can live anywhere. _config, like _config.php, is special - it has to live at the root of a module, and each module needs at least one.

It also has the side-effect of making it show up at the top in an alphabetical listing.

Do the numbers have to be at the beginning?  It seems like the priorities have more do to with resolving priorities between modules than within on, which means that sorting the contents of subsites/_config/ by priority is of limited use. 

Just that "sorted alphabetically" is easy, and numbers at the end, or in the file itself, are a bit less obvious

Do we want to spell out some priority categories so that people know which numbers to pick as a starting point?  That'll help avoid the z-index arms-race that you get in CSS sometimes. ;-)

Yeah. Deb package sources do the same thing. You're a hundred higher than I'd like though - I though 000 would be sapphire.

Hamish Friedlander

SilverStripe

[Sam Minnée]

> // fallback for environment file lacking configuration
> if(!defined('SS_API_HOST')) define('SS_API_HOST',
> Director::absoluteBaseURL() . '/ui/web/htdocs');

This raises a point: to we want to bring the _ss_environment.php configuration into this brave new world? Right now it's out-of-the-box behaviour is *nothing* except for DEFINing stuff. I think we can improve on this.

The above configuration would then be a config file with a lower priority than the environment file.

Going on from my previous email, I'd suggest that environments are set as priority 800 (lower than the project, but higher than everything else)

One other thing: when setting up a site in cloud-host phpfog, I put my ss_environment configuration into php.ini, which worked well. I'd suggest that we cater for this somehow if we can.

[Will Rossiter]

It's nice to have fragments as an option, but it seems like the kind of thing that we should only have to use if we need to.  Ideally for simple sites we can just have mysite/_config/mysite.yml  or something.

What about setting the priorities inside the yaml file? that would allow you to alter multiple priority levels without having to spilt into multiple files. Though I can't find any instances where I've needed to do this.

I'm guessing that your class_exists() thing is having configuration that varies depending on whether or not a module is installed, or when a specific version of that module is installed.

It's actually if a PHP function exists or not (5.3 vs 5.2) since production uses 5.2 and I'm working on 5.3

[Sam Minnee]

> I imagined this might work by having subdirectories of _config, so
>
> mysite/_config/dev/500-dev-database.yml

It looks nice for environment, but I don't know if this will scale
very well to the number of different optional that we're talking
about.

For example, subsites/_config/dev/if-newsletter-installed/php-5.3 is a
bit of a mouthful. :-P

[Hamish Campbell]

Hi,

Surely this should be informed by the Module Manager (which I'm
surprised to hear might not make it to 3.0 - happy to put some time in
here to see that happen). Dependency management and configuration is
the real problem that MM is supposed to solve (importing from source
is just a fancy feature on top, from a developer POV). To that end, I
suspect that a numbering system is insufficiently powerful, flexible
or reliable to meet those needs.

Until dependency management requirements have been specced it won't be
possible to determine if the proposed system will be future proof.

Hamish

On Mar 17, 3:07 pm, Hamish Friedlander <ham...@silverstripe.com>
wrote:

> Hi All,
>
> Part of the work we're looking to do for SilverStripe 3 is to add a static
> configuration layer. This will become the preferred configuration system,
> although _config.php will remain both to support legacy code & because some
> configuration needs to be set dynamically. This has several advantages,
> mostly around performance:
>
> - Classes won't get auto-included (and won't auto-include their
> dependancies) just to set configuration
>
> - The resulting configuration can be cached, reducing start up time
>
> - Configuration fragments can be provided at different priorities and for
> different environments, making it easier for modules to provide defaults per
> environment (live, dev, etc) and override other modules defaults
>
> === Setting configuration variables ===
>
> I've worked up a demonstration of how I think the configuration could look

> and put it on github athttps://github.com/hafriedlander/silverstripe-config-experiment. This isn't

[DesignCity]

I won't pretend to understand the entirety of this thread, however I
want to make sure we're not making things too complicated for simple
sites, or perhaps more importantly, making the learning curve for SS
steeper than it needs to be. For example, we seem to be fracturing the
config (more than it already is), introducing the requirements for the
developer to understand YAML and relationships all ss modules have to
eachother. We constantly run into module priority issues, however I'm
sure 80% of developers don't, so why make them think about it?

Looking forward to continue lurking in the discussion guys, just
possibly something to consider :)

Michael

On Mar 17, 10:07 am, Hamish Friedlander <ham...@silverstripe.com>
wrote:

> Hi All,
>
> Part of the work we're looking to do for SilverStripe 3 is to add a static
> configuration layer. This will become the preferred configuration system,
> although _config.php will remain both to support legacy code & because some
> configuration needs to be set dynamically. This has several advantages,
> mostly around performance:
>
> - Classes won't get auto-included (and won't auto-include their
> dependancies) just to set configuration
>
> - The resulting configuration can be cached, reducing start up time
>
> - Configuration fragments can be provided at different priorities and for
> different environments, making it easier for modules to provide defaults per
> environment (live, dev, etc) and override other modules defaults
>
> === Setting configuration variables ===
>
> I've worked up a demonstration of how I think the configuration could look

> and put it on github athttps://github.com/hafriedlander/silverstripe-config-experiment. This isn't

[Ingo Schommer]

Hey Hamish,

Great stuff, I'm really looking forward to cleaning up the configuration interface.

I'll make a couple of Symfony references below. They rely heavily on YAML config (some might say too heavily),

but it also means they would've encountered lots of edge cases that can be helpful examples for us.
Some sample config from them: http://symfony.com/doc/2.0/reference/bundle_configuration/DoctrineBundle.html

On Thursday, March 17, 2011 3:07:59 PM UTC+13, Hamish Friedlander wrote:

The format of the config fragments is mostly YAML, but with a few extensions:

- Values can start with a = (see mysite/_config/200-couchdb.yml) to specify PHP values, or =& (see mysite/_config/500-project.yml) to specify references to other config values

- Ordered lists normally add more items to any existing items in the list. Values can start with a ! to mean "remove this item from the list if it exists" (see subsites/_config/101-reports.yml). Potentially there'd be a syntax to say where in the list to add items (see cms/_config/100-cms-editor-config.yml).

# YAML Extensions: Array

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/sapphire/_config/100-shortcode-handler.yml

I think we should only extend YAML with custom syntax where the language doesn't provide a solution already. YAML already has associative arrays and lists.

Its going to be confusing if we allow *some* PHP like array(...) - assuming we don't eval() everything behind an equals sign, right?

Particularly as we use custom symbols elsewhere that have slightly different meaning in PHP (ampersand for reference, exclamation mark for negation).

# YAML Extensions: Constructors

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/sapphire/_config/100-password-encryptors.yml

PasswordEncryptor_LegacyPHPHash("md5") - Would this string be passed to Object::create()? I guess it'd be dependent on the class consuming the configuration setting to interpret this as a constructor?

# YAML Extensions: List manipulations

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/subsites/_config/101-reports.yml

YAML allows list merging and replacement already, although it needs defined anchors (with ampersand) and ugly.

See http://en.wikipedia.org/wiki/YAML#Data_merge_and_references

I think Hamish's format is superior, but it has the potential to break YAML parsers and formatting in IDEs.

So we're assuming to significantly extend an existing YAML parser?

# YAML Extensions: Constant checks

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/mysite/_config/200-couchdb.yml

I'd prefer Sam's approach of replacing _ss_env (and its PHP defines) with a lower priority YAML config

that would live outside of the webroot in order to configure multiple sites at once. In terms of legacy support,

we'd probably need to duplicate this information for a while in both formats.

The || syntax could still be useful though.

Symfony allows constants, but denotes them with percentages: http://www.symfony-project.org/reference/1_4/en/03-Configuration-Files-Principles#chapter_03_constants

# PHP Execution

Symfony allows PHP execution through <?php ?> tags, see http://www.symfony-project.org/reference/1_4/en/02-YAML#chapter_02_dynamic_yaml_files

# Priority

I'd prefer a "priority: " toplevel key in YAML files rather than ugly file names -

mainly because I like to get the big picture of configuration settings without opening a dozen files.

[Hamish Friedlander]

I've tried to keep any extensions valid YAML, so we can still use a regular parser, and just post-process it afterwards.

 

# YAML Extensions: Array

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/sapphire/_config/100-shortcode-handler.yml

I think we should only extend YAML with custom syntax where the language doesn't provide a solution already. YAML already has associative arrays and lists.

Its going to be confusing if we allow *some* PHP like array(...) - assuming we don't eval() everything behind an equals sign, right?

Particularly as we use custom symbols elsewhere that have slightly different meaning in PHP (ampersand for reference, exclamation mark for negation).

Um, = will end up being evaled maybe? This could easily be replaced by a yaml array in this instance, but the value of sitetree_link is a callback, which might be array(new Foo(), 'method') - obviously not do-able in yaml.

 

# YAML Extensions: Constructors

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/sapphire/_config/100-password-encryptors.yml

PasswordEncryptor_LegacyPHPHash("md5") - Would this string be passed to Object::create()? I guess it'd be dependent on the class consuming the configuration setting to interpret this as a constructor?

Yeah. The config layer would just see it as a string, and it's up to whatever consumes the config to do something sensible with it

 

# YAML Extensions: List manipulations

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/subsites/_config/101-reports.yml

YAML allows list merging and replacement already, although it needs defined anchors (with ampersand) and ugly.

See http://en.wikipedia.org/wiki/YAML#Data_merge_and_references

I think Hamish's format is superior, but it has the potential to break YAML parsers and formatting in IDEs.

So we're assuming to significantly extend an existing YAML parser?

As far as I could tell, data merge & reference is only for _hashes_, not ordered lists - yaml differentiates between array(a => b, c => d) and array(1,2,3) style arrays. This extension is explicitly for ordered lists

# YAML Extensions: Constant checks

https://github.com/hafriedlander/silverstripe-config-experiment/blob/master/mysite/_config/200-couchdb.yml

I'd prefer Sam's approach of replacing _ss_env (and its PHP defines) with a lower priority YAML config

that would live outside of the webroot in order to configure multiple sites at once. In terms of legacy support,

we'd probably need to duplicate this information for a while in both formats.

Yeah, I think I do too.

 

The || syntax could still be useful though.

Maybe. It's not PHP, so if = means eval, it'll need special handling, which I don't like

# PHP Execution

Symfony allows PHP execution through <?php ?> tags, see http://www.symfony-project.org/reference/1_4/en/02-YAML#chapter_02_dynamic_yaml_files

Part of the point of these files is that they can be cached and re-used. How would that work with arbitrary PHP? Not saying it couldn't, but we'd have to have rules around what that would mean.

# Priority

I'd prefer a "priority: " toplevel key in YAML files rather than ugly file names -

mainly because I like to get the big picture of configuration settings without opening a dozen files.

I see it the other way - priority in file names lets you see the order without having to open every file up by just doing a "ls */_config/*.yml"

 

I'm not against putting priority inside config files though, just don't prefer it. I actually don't see those numbered filenames as ugly, but I guess others do.

Hamish Friedlander

SilverStripe

[Ingo Schommer]

On Friday, March 18, 2011 4:34:33 PM UTC+13, Hamish Friedlander wrote:

# Priority

I'd prefer a "priority: " toplevel key in YAML files rather than ugly file names -

mainly because I like to get the big picture of configuration settings without opening a dozen files.

I see it the other way - priority in file names lets you see the order without having to open every file up by just doing a "ls */_config/*.yml"

I think we won't get around some form of debugging the actually generated config file (rather than inspecting files),

which could be as simple as a YAML dump viewer. With this assumption, I don't have any strong feelings on file vs. inline priorities,

other than ugly filenames ;)