Internal types leaking into public API about optparse-applicative HOT 6 CLOSED

Maybe also some or all of the types in the .Types module, especially Parser itself, but maybe not the (term-level) constructors. Another option is to export the .Internal types from .Types.

Currently I need three different imports for optparse, one of which is internal.

from optparse-applicative.

I did the exact same thing and had the exact same issue.

from optparse-applicative.

I added some exports in Builder. Does that fix the issue?

from optparse-applicative.

It does fix the issue of having to import .Internal in my case, although I'd still like for at least Parser to be exported from Options.Applicative in some way.

In my particular case I also need import Options.Applicative.Types (Completer(..)) because I'm getting completions from a database and doing the prefix check myself in the query as an optimization (listIOCompleter would be slower), but perhaps that's a special case, or perhaps the right solution for that would be to add a completer = Completer to Options.Applicative.Builder.Completer or something?

from optparse-applicative.

although I'd still like for at least Parser to be exported from Options.Applicative in some way

But it is, isn't it? It comes from Common.

In my particular case I also need import Options.Applicative.Types (Completer(..)) because I'm getting completions from a database and doing the prefix check myself in the query as an optimization

Yeah, that's reasonable. I've now added mkCompleter = Completer and exports.

from optparse-applicative.

Cool, thanks!

from optparse-applicative.