On Sat, 15 Oct 2016 12:25:28 GMT, Sönke Ludwig wrote:

On Wed, 12 Oct 2016 17:35:33 GMT, Alessandro Bianciotto wrote:

On Tue, 11 Oct 2016 22:10:27 +0200, Sönke Ludwig wrote:

Currently the path is fixed and the sources would have to be edited
manually. The problem is that the file is read before any application
code is run (vibe.core.core's shared static this is the first to
trigger the lazy config file load).

One possibility would be to define an environment variable that can be
set, another would be to add the possibility to add additional
configuration files in /etc/vibe.conf (or using a command line option).

Alternatively, an API function that loads an additional configuration
file could be added, but it would only work for options that are read
after the function was called, which excludes any of vibe.d's default
options.

Thank you for your reply,
I'm not that knowledgeable about vibe.d to be able to judge what the best approach could be: in this you're in a much better position than me. In the end it depends a lot on whether you use the default or custom main, as well as on the individual use case.
I guess the quickest option would be to have the path/name of the config file to be specified in an environment variable as you suggest, but personally I would favour an API function processing the args at runtime, as you also suggested.
Do you think this may land in the core.args module?

I think a pretty safe thing to add would be a command line switch that causes additional configuration files to be parsed. What would also make sens is to extend the search path to the executable directory, so that a configuration file can be placed alongside the application.

The API function feels a little brittle, but maybe something like versions "VibeCustomConfigSearchPath" in dub.sdl + a public extern(C) string[] getConfigFileCandidates(); defined in the application and referenced by vibe.core.args could provide a functionally clean solution (would just not work if vibe.d is built as a dynamic/shared library.

Yes, I think adding a command-line switch for specifying the configuration file to be parsed would work very well and, I guess, it would complement the existing API pretty well.