Provide a sibling package for console applications

[kerscher]

Many things are only needed once you write a console application, but become almost always imported. This means probably a rio-executable, rio-executable-unix, etc with:

• optparse-applicative
• POSIX error codes and signals in scope
• Conduit

Since it’s almost expected you will either be streaming to-and-from stdout, stderr and stdin and should play nice with the calling processes and shells reporting return codes.

[chrisdone]

I wouldn't mind just importing rio and having those things brought in. Why bother splitting it up?

[chrisdone]

But importing e.g.

import qualified Rio.Exe as Exe

and that would bring in optparse-applicative's API, where you'd write e.g.

import qualified Rio.Exe as Exe
options = Exe.strOption (Exe.long "username" <> Exe.short 'U') <> ...
main = do
  (opts, level) <- Exe.options "1.0" "header" "desc" .. options ...
  Exe.runLogging level (start opts)
start opts = ...

Or something like that would be pretty neat.

[kerscher]

Well, some people might be creating a library that’s only defining a few datatypes and functions around them, and would (probably) not be interested in having to bring in system functionality on their compile cycles — even with Stack cacheing and everything. Maybe I’m being paranoid.

[snoyberg]

optparse-applicative does pull in a number of dependencies, I would imagine that would be a good one to put into a sibling library due to dependency footprint.

[NorfairKing]

I like the idea of the sibling package for executables.