Announcing opt-env-conf


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


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 will refresh their indexes. :slight_smile:


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
  - 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