optparse-generic

Auto-generate a command-line parser for your datatype

Version on this page:1.4.8@rev:1
LTS Haskell 20.15:1.4.9
Stackage Nightly 2023-03-24:1.4.9
Latest on Hackage:1.4.9

See all snapshots optparse-generic appears in

BSD-3-Clause licensed by Gabriella Gonzalez
Maintained by GenuineGabriella@gmail.com
This version can be pinned in stack with:optparse-generic-1.4.8@sha256:ed1f1601d8d4b573e27b569710e9a2d7579110665d82af832d301f2ebc46f065,1868

Module documentation for 1.4.8

Used by 3 packages in lts-19.27(full list with versions):
dhall-bash, github-release, require

This library auto-generates an optparse-applicative-compatible Parser from any data type that derives the Generic interface.

See the documentation in Options.Generic for an example of how to use this library

Changes

1.4.8

1.4.7

1.4.6

  • Use readField in default implementation of parseField

1.4.5

1.4.4

  • readIntegralBounded: use metavar in error message

1.4.3

  • Export internal readIntegralBounded utility
  • Build against optparse-applicative-0.16.0.0

1.4.2

  • New unwrap function
    • This is the underlying utility that powers unwrap{Record,RecordPure,WithHelp}

1.4.1

  • Fix broken haddocks

1.4.0

  • BREAKING CHANGE: Add support for type-level default values
    • This is a breaking change because the various parse* typeclass methods now take an additional argument to support this feature

1.3.1

  • Export GenericParseRecord and getRecord{,PureWith}

1.3.0

  • BREAKING CHANGE: New metavar method for ParseField class
    • This field simplifies customizing ParseField instances
      • Now you usually only need to override metavar now or possibly also readField, whereas the default behavior for parseField should work more often
    • This is only a breaking change for data types that use the default implementation of ParseField but do not derive Typeable
    • You can migrate existing code that doesn’t compile by just explicitly specifying what the metavar field should be
A service provided by FP Complete