Closed dcastro closed 1 year ago
Do I understand it correctly, that Dhall does not handle reading the environmental variables for us and we will have to write env variables reading + merging logic ourselves?
There is a relatively old package in Serokell called loot-config that already allows for configs formed from yaml config + environmental variables. Maybe we could use it; we will lose neat complex expressions and URLs following provided by Dhall, but our setting seems simple enough.
(disclaimer: env variables are yet not merged in loot-config, but I can finish that)
Do I understand it correctly, that Dhall does not handle reading the environmental variables for us and we will have to write env variables reading + merging logic ourselves?
Good question - I'm not sure, haven't looked too much into dhall yet (actually suggested using it here as an excuse to explore it :grin:). But this seems to suggest we might be able to pull it off (?).
There is a relatively old package in Serokell called loot-config that already allows for configs formed from yaml config + environmental variables.
Ooh interesting! Looks like it would fit the bill nicely.
(By the way, could you add some info about lootbox, loot-config, etc, to the new Internal Dev team page on notion?)
I think we could try Dhall first, see if that's doable - and if it gets too complex, or is not doable at all, then we give loot-config a try. Does that sound reasonable?
Yeah, sure, I also would like to take a chance to lear Dhall :)
By the way, could you add some info about lootbox, loot-config, etc, to the new Internal Dev team page on notion?
Really, would be nice to have it there.
Do I understand it correctly, that Dhall does not handle reading the environmental variables for us and we will have to write env variables reading + merging logic ourselves?
I guess something like this should work:
botToken = Some (env:SLACK_TZ_BOT_TOKEN as Text ? "<bot-token>")
Hm, if it is really such a simple one-liner, then very cool.
Do we really need dhall? It seems to be an overkill for me. Why not to use just yaml
(module Data.Yaml.Config) which allows to read config parameters from well-known yaml-format and can read environment variables without additional efforts?
Why not to use just yaml (module Data.Yaml.Config) which allows to read config parameters from well-known yaml-format and can read environment variables without additional efforts?
Diogo, who suggested using dhall
here, gives this motivation:
I actually suggested using it here as an excuse to explore it
So, if this is not the case for us, let's use yaml
, we really seem to need only the most basic functionality.
If you want to explore dhall configuration as well then let it be
If you want to explore dhall configuration as well then let it be
I'm perfectly OK with yaml, let's use it
Clarification and motivation
Right now, we have a very crude configuration parser: we use
getEnv
to read two environment variables,SLACK_TZ_APP_TOKEN
andSLACK_TZ_BOT_TOKEN
.We should implement a proper config parser. The app should look for a file named
config.dhall
(see: dhall), and parse the options below.appToken
/SLACK_TZ_APP_TOKEN
: requiredbotToken
/SLACK_TZ_BOT_TOKEN
: requiredmaxRetries
/SLACK_TZ_MAX_RETRIES
: optional, defaults to 3. This will be used in #5.cacheUsersInfo
/SLACK_TZ_CACHE_USERS_INFO
: optional, defaults to 1 hour. This will be used in #7.cacheConversationMembers
/SLACK_TZ_CACHE_CONVERSATION_MEMBERS
: optional, defaults to 1 minute. This will be used in #7.Environment variables take precedence over the config file. If all the required options are specified as environment variables, then a config file does not need to exist on disk.
Tip: we can use the
o-clock
package to express and parse units of time:Acceptance criteria