Initial port to os-string

[0rphee]

• Tests seem to pass: https://github.com/0rphee/optparse-applicative/actions (Though they have changed since most of the API is not longer in terms of String)
• Adjusted build-depends bounds and remove support to ghc <8.6 (due to process >= 1.6.26.0). Also, as mentioned in Support for ospath/osstring #491, filepath >= 1.5 and os-string >= 2.0.5 are needed.
  • This dependencies prevent the use of this new version in packages which depend on ghc as mentioned in Support for ospath/osstring #491.
• Since text is already a transitive dependency, so I also updated some of the API to use that instead of String.
  • As the output of prettyprinter is LazyText I've updated the API to not change this type.
  • I use Text.IO functions for printing.
• I'm not entirely sure of some of the encoding/decoding stuff, I've used unsafePerformIO . decodeLE, but also new functions Options.Applicative.Help.Pretty.osStringToStrictText (built in terms of ByteString -> Text functions). It would be nice if there was a straight OsString -> Text, instead of the need to pass through String or ByteString.
• For the moment I've left Options.Applicative.Help.Levenshtein as-is (using String), but the Options.Applicative.Builder.Completer (which has heavy use of uncons) module is updated, it's expected that Levenshtein would look like Completer.
• It'd be nice to have OsString.getProgName and OsString.readProcess in process.
• Docs & README are not updated yet.

[0rphee]

@HuwCampbell hi, sorry for the ping. Is OsString support planned? or should it be better to make a different package?

[hasufell]

@0rphee if upstream doesn't respond, then I'd be willing to maintain a fork.

[0rphee]

@hasufell sorry for the late response.

At the moment, and for the foreseeable future, I don't think that I am able to help in such endeavor. However, I fully support your intention to create a new package.

Regarding the code, I tried my best to keep everything as-is, but some of my biggest concerns are:

1. The distance algorithms since, if I remember correctly, I translate OsString -> String, and use the original code mostly unchanged.

2. The API. At first I thought it was better to keep most things as a drop in replacement, however, there were some changes that don't keep the change String-OsString 1:1. Maybe it would be nice to separate the OsString interface to a more primitive API, and on top of that, implement the previous String-based API. However, I imagine this is considerably more work than just maintenance.