No good way to create a 'Parsed' object

[floitsch]

It's currently common to call a method with the Parsed object:

  --run=:: foo it


foo parsed/cli.Parsed:
  ...

If I wanted to call the foo function directly, then I would need to create a Parsed object myself. That's currently not really possible.

We should either make this possible, or discourage passing the Parsed object around.

For example, we could encourage to always extract the options in the lambda:

  --run=:: foo it["option1"] it["option2"] ...

That could get messy, and would go against future API plans, where we would like to give a Cli object that has ui, config, and cache (in addition to parsed). That said, maybe parsed shouldn't be part of that object.

[erikcorry]

If it's just for testing then Map has a similar interface as Parsed, so leaving off the type annotation would work.

Slightly less hacky would be to have a TestingParsed that takes a map and implements the Parsed interface.

[floitsch]

I think it would also happen for something where one command wants to call out to another command (potentially after having done something).

So maybe the real Parsed should have a .from_map.