Closed newhoggy closed 1 year ago
@RyanGlScott I think this is a counterpart of https://github.com/pcapriotti/optparse-applicative/pull/428
optparse-applicative
recently made two releases that support prettyprinter
:
optparse-applicative-0.17.1.0
supports ansi-wl-pprint-1.*
, which re-exports prettyprinter
functionality.optparse-applicative-0.18.0.0
drops its ansi-wl-pprint
dependency and instead depends on prettyprinter
directly.I think we should follow suit in criterion
. I'll prepare a series of two PRs (based on the changes in #241 and #242) such that we will have:
criterion
release that supports optparse-applicative-0.18.*
, in addition to previous optparse-applicative
releases that use ansi-wl-pprint
.criterion
release that requires optparse-applicative-0.18.*
or later and explicitly depends on prettyprinter
.See #275 (which widens optparse-applicative
support) and #276 (which requires optparse-applicative-0.18.*
as the minimum).
I've released criterion-1.6.1.0
and criterion-1.6.2.0
to Hackage, which include the changes from #275 and #276, respectively. As such, this PR has been superseded, so I'll close this.
Thanks for the PR, @newhoggy. I'm a bit unclear on what the purpose of this PR is. Is the goal to replace the use of
ansi-wl-pprint
withprettyprinter
? If so, thenoptparse-applicative
(a dependency ofcriterion
) will need to be patched first, as itsfooterDoc
function (whichcriterion
uses) makes use ofansi-wl-pprint
'sDoc
type rather thatprettyprinter
'sDoc
.The PR title mentions something about
optparse-applicative
master
, but as far as I can tell, themaster
branch ofoptparse-applicative
still usesansi-wl-pprint
, and the PR itself doesn't change the version ofoptparse-applicative
being used. As things stand, I'm uncertain how this is meant to work.