Closed Licenser closed 7 years ago
That's exactly my use case as well, for that reason #318 was submitted and #319 implemented it, the include paths are relative to the file that's doing the inclusion, i typically use a hierarchical structure (kinda like config inheritance):
- dev/mobile/vars.config
- dev/web/vars.config
- dev/vars.config
- vars.config
each of these files is being included by the one in the next folder so you just need to specify one overlay var file (eg. dev/mobile/vars.config
)
That sounds really awesome! and very close to what I try to do :D.
But I'm quite confused so how to use it / how it works. Is there any docs on that?
i was going through the wiki, though i had created some at the time but can't find anything, i'd be happy to guide you in exchange for a wiki entry on it, sounds good?
Always!
ping me on slack then, easier that way (@luis.rascao)
which slack? ^.^
I have run into the situation rather frequently that I have multiple sets of overlay variables. A number of basic variables that are fixed, and a set of variables that chage. The simplest example would be having a
build_type
variable that can be either"development"
oder"production"
.Right now I keep two copies of the
vars.conf
for each instance that are virtually identical with one difference. This process is quite error prone, as anyone who knows me knows I can't be trusted and will eventually forget to update something and those configurations start to diverge.Now if I have multiple files I could have a
base.conf
with all the shared variables, aprod.conf
with code that's set for production and adev.conf
for development. With base being exactly the same file there is no chance of it diverging beyond builds.