Announcing opt-env-conf

https://cs-syd.eu/posts/2024-07-08_announcing-opt-env-conf

18 Likes

Oh snap, I love this! :heart:

Will this be uploaded to Hackage/Stackage at any point?

1 Like

It’s already on hackage :slight_smile:

Oh really?
Using this search on hoogle I could not find it :thinking:
Is that just hackage/hoogle needing to refresh its cache, or does it have to be in stackage before you can find it on hoogle?

Looks awesome!!! :100:Will try it out. Thanks for sharing. :+1:

1 Like

image

1 Like

Hoogle does list packages that are “Not on Stackage”

1 Like

This is mainly why I thought hoogle searched all of hackage :thinking:

Then I guess in the next 24 hours both Hoogle and Flora.pm will refresh their indexes. :slight_smile:

4 Likes

Wonderful! Especially the feature to freely move a config between command-line, config-file and environment. What limitations does the Applicative-not-Monadic design bring? For example, can one have cascading configuration files, where one master config defines more sub-configs to parse? Should mapIO and filePathSetting be used for that?
And could an option determine the set of permissible further options or is that inherently monadic? I am thinking about

# jobs.yaml
jobs:
  - build
  - deploy
  - test

# valid call:
myProg --config jobs.yaml --run build --run test
# invalid call, "explode" not present in jobs.yaml
myProg --config jobs.yaml --run build --run explode

Would it be possible to extend the package with user-defined file parsers, e.g. where tabular configuation is more efficient or does that conflict with help text generation?

This is great, thanks. You could try doing all this with Template Haskell and Lint at compile time while retaining simple types, though!

1 Like